diseño e implementación

Departamento de InformáticaDepartamento de InformáticaUniversidad Técnica Federico Santa MaríaUniversidad Técnica Federico Santa María

Diseño e ImplementaciónDiseño e Implementación

Diseño al nivel de componentes

Pedro Francisco Godoy BarreraPedro Francisco Godoy BarreraDiseño e Implementación de SistemasDiseño e Implementación de Sistemas

Introducción

• ¿Qué és?: Un conjunto completo de componentes del SW se define durante el diseño arquitectónico, pero las estructuras de datos internas y el procesamiento de detalles de cada componente no se representan en un grado de abstracción parecido al código.

• El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las características de la interfaz y los mecanismos de comunicación asignados a cada componente del SW.


Introducción

• ¿Quién lo hace?: Un ingeniero de SW realiza el diseño a nivel de componentes.

• ¿Por qué es importante?: Antes de construir el SW se debe tener la capacidad de determinar si funcionará bien.

• El diseño a nivel de componentes representa el SW de tal manera que permite revisar si los detalles del diseño son correctos y consistentes con las representaciones iniciales del diseño (es decir, los diseños de datos, arquitectura e interfaz).

• Proporciona una manera de evaluar si funcionarán las estructuras, las interfaces y los algoritmos.


Introducción

• ¿Cuáles son los pasos?: Las representaciones al nivel de diseños de datos, arquitectura e interfaz representan la base del diseño al nivel de componentes.

• La definición de clase o la narrativa de procesamiento de cada componente se traduce en un diseño detallado que usa diagramas o formas de texto que especifican estructuras de datos internas, detalle de la interfaz local y lógica de procesamiento.

• La notación de diseño abarca diagramas UML y representaciones complementarias.

• El diseño procedimental se especifica mediante un conjunto de construcciones de programación estructurada.


Introducción

• ¿Cuál es el producto obtenido?: El diseño de cada componente, representado en una notación gráfica, tabular o textual, es el principal producto de trabajo creado durante el diseño a nivel de componente.

• ¿Cómo puedo estar seguro de que lo he hecho correctamente?: Se realiza un recorrido o una inspección al diseño. Éste se examina para determinar si las estructuras de datos, las interfaces, las secuencias y las condiciones lógicas son correctas y para ver si arrojan los datos apropiados o la transformación de control asignada al componente durante las primeras etapas del diseño.


1 ¿Qué es un componente?

• De manera general, un componente es un bloque de construcción modular para el SW de cómputo.

• De manera formal, un componente es “una parte modular, desplegable y reemplazable de un sistema que encapsula implementación y expone un conjunto de interfaces”.

• Los componentes pueblan la estructura del SW, y por tanto, ayudan a cumplir con los objetivos y requisitos del sistema en construcción.

• Debido a que los componentes residen en el interior de la arquitectura del SW, deben comunicarse con otros componentes y con entidades (como sistemas, dispositivos, personas) que existen fuera de los límites del SW.



1.1 Concepto Orientado a Objetos• Un componente contiene un conjunto de clases que

colaboran entre si.• Cada clase de un componente se ha elaborado

completamente para incluir todos los atributos y las operaciones relevantes para su implementación.

• Cómo parte de la elaboración del diseño también deben definirse todas las interfaces (mensajes) que permiten que las clases se comuniquen y colaboren con otras clases de diseño.



1.1 Concepto Orientado a Objetos• Para lograrlo el diseñador empieza con el modelo de

análisis y elabora:– Clases de análisis (en el caso de componentes que se

relacionan con el dominio del problema)

– Clases de infraestructura (en el caso de componentes que proporcionan servicios de soporte para el dominio del problema).

• Ej: Desarrollo de SW para una imprenta sofisticada, cuyo objetivo general es recopilar las necesidades del cliente en el mostrador, cotizar un trabajo de impresión y pasarlo a una planta de producción automatizada.



Trabajo Imprenta

Nº de páginasNº de ladosTipo PapelAmpliaciónCaracterísticas producción

Calcular costo trabajo()Imprimir y pasar trabajo()

Clase de análisis

Trabajo Imprenta

Componente de diseño

Iniciar trabajo

Calcular trabajo


Clase de diseño elaborado

Trabajo Imprenta

Nº de páginasNº de ladosTipo Papel Peso papel tamaño papel color papelAmpliaciónRequisitos ColorCaracterísticas producción Opciones distribución Opciones encuadernado portadas Almacén refine prioridad

Calcular costo página()Calcular costo trabajo()Imprimir y pasar trabajo()Calcular costo trabajo total()Revisar prioridad()Pasar trabajo a producción()

<<Interfaz>>Iniciar trabajo

ConstruirOrdenTrabajo()VerificarPrioridad()PasarTrabajoaProducción()

<<Interfaz>>calcular trabajo

CalcularCostoPagina()CalcularCostoPapel()CalcularCostoProd()CalcularCostoTrabajoTotal()



• 1.1 Concepto Orientado a Objetos– Deben especificarse las estructuras de datos

apropiadas para cada atributo.

– Se diseña el detalle algorítmico que se requiere para implementar la lógica de procesamiento asociada con cada operación.

– Se diseñan los mecanismos necesarios para implementar la interfaz (en OO esto abarca la descripción de todos los mensajes que se requieren para realizar la comunicación entre objetos dentro del sistema)



• 1.2 El concepto convencional– Un componente es un elemento funcional de un programa que

incorpora:• La lógica del procesamiento• Las estructuras internas de los datos necesarios para

implementar dicha lógica• Una interfaz que permita la invocación del componente y el paso

de los datos.

– El componente convencional, también denominado módulo, reside dentro de la arquitectura del SW y representa uno de tres papeles importantes1. Como componente de control, que coordina la invocación de

todos los demás componentes del dominio del problema.2. Como componente del dominio del problema que implementa

una función completa o parcial requerida por el cliente.3. Como componente de infraestructura responsable de funciones

que soportan el procesamiento requerido.



• 1.2 El concepto convencional– Al igual que en OO, los componentes del SW

convencional se derivan del modelo de análisis.– Pero en este caso el elemento de datos orientado

al flujo sirve como base para la derivación.• Cada Transformación representada en los niveles

inferiores del DFD se correlaciona directamente con una jerarquía de módulos.

• Los componentes de control (módulos) residen cerca de la parte superior de la jerarquía (arquitectura) y los componentes de dominio de problema tienden a residir hacia la parte inferior de la jerarquía.



• 1.2 El concepto convencional

Leer datos de Trabajo deImpresión

Sistema de Administración

De Trabajo

Seleccionar laFunción deManejo de

trabajo

DesarrollarCosto detrabajo

ConstruirOrden detrabajo

Enviar trabajoA producción

Calcular costoDe página

Calcular costo De papel

Calcular costoDe

producciónRevisar prioridad

Pasar trabajoA producción



• 1.2 El concepto convencional– Durante el diseño a nivel de componente, se

elabora cada módulo mostrado en la figura anterior.

• La interfaz de diseño se define de forma explicita, es decir, se representa cada objeto de datos o de control que fluye por la interfaz.

• El algoritmo que permite que el módulo realice su función está diseñado con el enfoque de refinamiento. El comportamiento del módulo suele representarse con un diagrama de estado.



• 1.2 El concepto convencional– Ej: Considérese el módulo CalcularCostoPagina

• Su Objetivo es calcular el costo de impresión por página a partir de las especificaciones del cliente. Los datos necesarios para la realización de la función son:

» Nº de páginas en el documento» Nº total de documentos que se producirán» Impresión por una o ambas caras» Color o blanco y negro» Tamaño.

• Estos datos se pasan a CalcularCostoPagina mediante la interfaz del módulo.

• Este usa los datos y determina un costo por página que se basa en el tamaño y la complejidad del trabajo (Una función de todos los datos pasados al módulo con la interfaz).

• El costo por página es inversamente proporcional al tamaño del trabajo y directamente proporcional a su complejidad.


Calcular costoDe página

AccesarBDcostos

ObtenerdatosTrabajos Componente del diseño

Costo Página

Entra: número de página Entra: Nº de documentos Entra: lados = 1, 2 Entra: color = 1, 2, 3, 4 Entra: Tamaño Página = A, B, C, D Entra: Costo de Página Entra: color = 1, 2, 3, 4 Sale: CBP Sale: CF

ObtenerDatosTrabajo(Nº de páginas,Nº de documentos, lados, color,Tamaño página, costo página)Accesar BD costos(Tamaño trabajo,Color, tamañoPagina, CBP, SF)Calcular Costo página()

Tamaño de trabajo (TT) = NºPaginas = NºDocumentos;Buscar costo Base de páginas(CBP) -> AccesarBDCostos(TT,color);Buscar Factor de Tamaño (FT) -> AccesarBDCostos(TT, color, tamaño)Factor de Complejidad de Trabajo (FCT)= 1 + [(lados -1)* costoLado + FT]costoPagina = CBP * FCT


2. Diseño de componentes basado en Clases

• El nivel de componentes se basa en información desarrollada como parte del modelo de análisis y representada como parte del modelo arquitectónico.

• Al elegir el método de Ingeniería de SW basado en componentes, el diseño al nivel de estos se concentra en:– La elaboración de las clases de análisis (clases específicas

del dominio del problema)

– Y la afinación y definición de las clases de infraestructura.

• La descripción detallada de atributos, operaciones y las interfaces empleadas por estas clases representa el detalle de diseño requerido como precursor de la actividad de construcción.


Principios Básicos del diseño de Principios Básicos del diseño de componentecomponente



• 2.1 Principios básicos de diseño– Hay 4 principios básicos de diseño aplicables al

diseño al nivel de componentes y se han adoptado ampliamente cuando se aplica Ingeniería de SW orientada a objetos.

– La idea central de estos principios es crear diseños que sean más sensibles al cambio y reducir la propagación de efectos secundarios cuando ocurren cambios.


2.1 Principios básicos de diseño

• El Principio Abierto-Cerrado (PAC)“El Módulo debe estar abierto para extensión, pero cerrado para

modificación”

• El diseñador debe especificar el componente de manera que permita extenderlo (dentro del dominio funcional que atiende) sin necesidad de modificaciones internas al propio componente (al nivel de código o lógica).

• Para esto el diseñador crea abstracciones que sirven como memoria intermedia entre la funcionalidad que tal vez habrá de extenderse y la propia clase de diseño.


<html><script languaje="JavaScript">var n,m,h,p;do

n = parseInt(prompt("Ingrese unn número entero",1));while((n<1)||(n>3));if(n==1){

document.write(“Sensor de Puerta y ventanas”);}else{ if(n==2)

{ document.write(“Sensor humo”);}else{ if(n==3)

{ document.write(“Sensor de movimiento”);}else{ document.write("Esta opción no está implementada");}

}}</script></html>


Detector

SensorPuertas/Ventana

Sensor humoDetector deMovimiento

Sensor CalorSensor

CO2

<<Interfaz>>Sensor

Leer()

Habilitar()

Inhabilitar()

Probar()



• 2.2 Principios de sustitución de Liskov“”Debe tenerse la opción de sustituir las subclases con sus clases

principales”• Un componente que use la clase principal debe seguir

funcionando apropiadamente si, en cambio, se pasa al componente una clase derivada.

• Para lograr esto, este principio exige que cualquier clase derivada de una clase principal se apegue a cualquier contrato implícito entre la clase principal y los componentes que la usan.

• En este contexto un contrato es una condición previa que deber ser verdad cuando el componente usa una clase principal y una condición posterior que debe ser cierta después que el componente usa la clase principal.

• Cuando un diseñador crea clases derivadas, estas también deben ajustarse a la condiciones previas y posteriores



• 2.3 Principio de inversión en independencia (PID)“Dependa de las abstracciones, no de las concreciones”

• acuerdo al principio del PAC, las abstracciones son el lugar donde el diseño se puede extender sin grandes complicaciones.

• Cuanto más dependa un componente de otros componentes concretos (en lugar de abstractos, como la interfaz) más difícil será extenderlos.



• 2.4 Principio de segregación de la interfaz (PSI)“Es mejor tener muchas interfaces especificas del cliente que una

interfaz de propósito general”

• Cuando varios componentes de cliente usan las operaciones proporcionadas por una clase servidor.

• El PSI sugiere que el diseñador debe crear una interfaz especializada para servir a cada categoría especial de cliente.

• Sólo las operaciones importantes para una categoría especial de clientes deben especificarse en la interfaz para esos clientes.

• Si varios clientes necesitan las mismas operaciones, deben especificarse en cada una de las interfaces especializadas.



• 2.4 Principio de segregación de la interfaz (PSI)

• Ejemplo: Clase PlanoCasa que se usa para funciones de seguridad y vigilancia– Funciones Seguridad: ColocarDispositivo(),

mostrarDispositiuvo(), agruparDispositivo(), y eliminarDispositivo()

– Funciones de Vigilancia: Estas además requieren de operaciones especiales para las cámaras: mostrarPV() y mostrarIDDispositivo().


Principios de EmpaquetamientoPrincipios de Empaquetamiento



• En muchos casos los componentes o las clases individuales se organizan en subsistemas o paquetes, no existen en el vacío.– ¿Cómo se debe presentar esta actividad de

empaquetamiento?

– ¿Cómo deben organizarse los componentes a medida que avanza el diseño?

• Para esto se sugieren principios adicionales de empaquetamiento que son aplicables al diseño a nivel de componentes



• Principio de equivalencia ente reutilización y versión (PER)

“La esencia de la reutilización es la misma que de la versión”• Cuando las clases o componentes se diseñan

para reutilizarlos, hay un contrato explícito entre el desarrollador de la entidad reutilizable y la persona que lo usará.

• Lo aconsejable es agrupar las clases reutilizables en paquetes que se pueden manejar y controlar a medida que evolucionan nuevas versiones.



• Principio del cierre común (PCC)“Las clases que cambian juntas deben permanecer juntas”

• Las clases deben empaquetarse de manera que sean un todo coherente, es decir, cuando las clases se empaquetan como parte de un diseño, deben atender la misma área de funciones o comportamiento.

• Esto lleva a un control de cambio y a un manejo de versiones más efectivo



• Principio común de la reutilización (PCR)“Las clases que no se reutilizan juntas no deben agruparse juntas”

• Cuando una o más clases cambian en un paquete, también cambia el número de versión del paquete.

• Todas las demás clases o paquetes que dependen de ese paquete deben actualizarse ahora a la versión más reciente del paquete y probarse para asegurar que la nueva versión funciona sin incidentes.

• Si no hubo cohesión al agrupar las clases, es posible que cambie una clase que no tenga relación con las demás.

• Esto requerirá un proceso innecesario de integración y de prueba. Por esto, sólo deben incluirse en un mismo paquete las clases que se reutilizarán juntas.


Líneas generales de diseñoLíneas generales de diseño


2.2 Líneas generales de diseño al nivel de componentes

• Componentes: Deben definirse convenciones de asignación de nombres para componentes especificados como parte del modelo arquitectónico, y luego refinarse y elaborarse como parte del diseño al nivel de componentes.

• Los nombres del modelo arquitectónico deben extraerse del dominio del problema y tener algún significado para los participantes que ven el modelo arquitectónico

• Ej: la clase PlanoCasa al nivel arquitectónico



• Interfaces: Las interfaces proporcionan información importante acerca de la comunicación y la colaboración (además de ayudar a lograr el PAC).

• Sin embargo, una representación libre de las interfaces tiende a complicar los diagramas del componente.



• Dependencias y Herencias:

• Para mejorar la legibilidad es buena idea modelar las dependencias de izquierda a derecha y la herencia de abajo (clases derivadas) hacia arriba (clases principales).

• Además las interdependencias entre los componentes deben representarse mediante interfaces, en lugar de hacerlo mediante la representación de una dependencia de componente a componente. Siguiendo la filosofía del PAC.

• Esto ayuda a mejorar las opciones de mantenimiento del sistema


2.3 Cohesión

• En el contexto del diseño al nivel de componentes para sistemas orientados a objetos, la cohesión implica que un componente o una clase sólo encapsula atributos y operaciones relacionadas estrechamente entre sí y con la clase del propio componente.

• Funcional: Exhibido principalmente para operaciones, este grado de cohesión se presenta cuando un módulo realiza un solo cálculo y luego devuelve un resultado.


2.3 Cohesión• De capa: Exhibido para paquetes, componentes y clases,

este tipo de cohesión ocurre cuando una capa superior tiene acceso a los servicios de una inferior, pero ésta no tiene acceso a aquélla.

Panel de control

Detector Teléfono

Modem

T-com


2.3 Cohesión

• Comunicación: Todas las operaciones con acceso a los mismos datos se definen dentro de una clase. En general, esa clase sólo se concentra en los datos en cuestión, accesándolos y almacenándolos.

• Resulta relativamente fácil implementar, probar y mantener las clases y los componentes que muestran cohesión funcional, de capa y de comunicación.

• El diseñador debe luchar por alcanzar estos grados de cohesión.


2.3 Cohesión

• Secuencial: Los componentes o las operaciones están agrupados de manera que el primero permita la entrada al siguiente, y así sucesivamente. El objetivo es implementar una secuencia de operaciones.

• Procedimental: Las componentes o las operaciones están agrupados de manera que permitan la invocación de uno inmediatamente después de que se invoque el anterior, aunque no se hayan pasado datos entre ellos.

• Temporal: Las operaciones que se realizan reflejan un comportamiento o estado específico, como una operación que se realiza al principio o todas las operaciones realizadas cuando se detecta un error.


2.3 Cohesión

• Utilitaria: Se han agrupado componentes, clases u operaciones que existen dentro de la misma categoría, pero que no tienen otra relación.

• Por ejemplo: una clase llamada estadística muestra cohesión utilitaria si contiene todos los atributos y las operaciones necesarios para calcular seis medidas estadísticas simples.

• Estos grados de cohesión son menos deseables y deben evitarse cuando existen otras opciones de diseño, sin embargo, es importante tomar en cuenta que a veces los temas pragmáticos de diseño e implementación obligan al diseñador a optar por los grados inferiores de cohesión


2.4 Acoplamiento

• El acoplamiento es la medida cualitativa del grado al que las clases de conectan entre sí. A medida que las clases y (los componentes) se vuelven más interdependientes, el acoplamiento aumenta.

• Un objetivo importante en el diseño al nivel de componentes consiste en mantener el acoplamiento lo más bajo posible.

• El acoplamiento de clases se manifiesta de varias formas:• Acoplamiento de contenido: Ocurre cuando un

componente modifica “a escondidas” datos internos de otro”. Esto viola la ocultación de información.


2.4 Acoplamiento

• Acoplamiento común: ocurre cuando varios componentes usan una variable global, aunque esto es necesario en algunas ocasiones (para establecer valores predeterminados en toda la aplicación), el acoplamiento común puede llevar a la programación incontrolable de errores y a efectos colaterales imprevisibles cuando se hacen cambios.

• Acoplamiento de control: Se presenta cuando la operación A() invoca la operación B() y pasa una marca de control a B.

• La marca de control dirige entonces el flujo lógico dentro de B

• El problema es que un cambio no relacionado en B puede causar la necesidad de cambiar el significado de la marca de control que pasa A.


2.4 Acoplamiento

• Acoplamiento de estampa: Ocurre cuando claseB se declara como tipo para un argumento de una operación de claseA. Debido a que claseB ahora es parte de la definición de claseA, la modificación del sistema se vuelve más compleja.

• Acoplamiento de datos: ocurre cuando las operaciones pasan cadenas largas de argumentos de datos. “El ancho de banda” de la comunicación entre clases y componentes crece y la complejidad de la interfaz aumenta. La prueba y el mantenimiento son más difíciles.


2.4 Acoplamiento

• Acoplamiento de llamada a rutina: ocurre cuando una operación invoca a otra. Este grado de acoplamiento es común y, a menudo muy necesario. Sin embargo, aumenta la conectividad del sistema.

• Acoplamiento de uso de tipo: Ocurre cuando el componente A usa un tipo de datos definidos en el componente B (por ejemplo, esto ocurre cada vez que “una clase” declara una variable de instancia o una local como si estuviera otra clase para su tipo”). Si cambia la definición del tipo, también deben cambiar todos los componentes que usan la definición.


2.4 Acoplamiento

• Acoplamiento de inclusión o importación: ocurre cuando el componente A importa o incluye un paquete o el contenido del componente B.

• Acoplamiento externo: Ocurre cuando un componente se comunica o colabora con componentes de infraestructura (como las funciones del sistema de operación, capacidad de la base de datos, las funciones de comunicación). Aunque este tipo de acoplamiento es necesario, debe limitarse a un pequeño número de componente o clases de un sistema


2.4 Acoplamiento

• El SW debe comunicarse interna y externamente. Por tanto, el acoplamiento es fundamental. Sin embargo, el diseñador debe trabajar para reducir el acoplamiento cada vez que sea posible y comprender las ramificaciones de un acoplamiento elevado cuando no pueda evitarse.


Conducción del Diseño a nivel de Conducción del Diseño a nivel de componentescomponentes


3. Conducción del diseño al nivel de componentes

• El diseño al nivel de componente es de naturaleza elaborativa.

• El diseñador debe transformar la información del análisis y los modelos arquitectónicos en una representación de diseño que proporcione suficiente detalle para guiar la actividad de construcción (codificación y prueba).

• Los siguientes pasos representan un conjunto de tareas típicas para el diseño al nivel de componentes, al aplicar el sistema orientado a objetos:



• Paso 1: Identificar todas las clases de diseño que corresponden al dominio del problema.

• Paso 2: Identificar todas las clases de diseño que corresponden al dominio de la infraestructura.– Estas clases no se describen en el modelo del análisis y a

menudo faltan en el modelo arquitectónico, pero deben describirse acá.

• Paso 3: Elaborar todas las clases de diseño que no se adquieran como componentes reutilizables.– La elaboración requiere que se describan de manera

detallada todas las interfases, los atributos y las operaciones necesarias para implementar la clase. Al realizar esta tarea debe tomarse en cuenta el diseño de la heurística (Por ej: la cohesión y el acoplamiento de componentes)



• Paso 3a: Especificar los detalles del mensaje cuando las clases o los componentes colaboran.– El modelo de análisis emplea el diagrama de

colaboración para mostrar la manera en que las clases de análisis colaboran entre sí.

– Acá es útil mostrar los detalles de estas colaboraciones, especificando la estructura de mensajes que se pasan entre los objetos del sistema. (opcional, pero puede usarse como el inicio de la especificación de interfaces ya que muestran la manera en que se comunican y colaboran los componentes del sistema.



• Paso 3a: TrabajoProducción

ColaTrabajoOrdenTrabajo

1: ConstruirTrabajo (númeroOT) 2: RemitirTrabajo (númeroOT)

[condición guardia] Expresión de secuencia (valor devuelto): =Nombre del mensaje (lista de argumentos)

Condición guardia = Especifica cualquier conjunto de condiciones que deben cumplirse antes de enviar el mensaje

Expresión de secuencia: es un valor entero que indica el orden secuencial en que se envía un mensaje

(Valor devuelto) es el nombre de la información que devuelve la operación que se invoca por el mensaje

Nombre del mensaje Identifica la operación que se invoca

(Lista de argumento) es la lista de los atributos que se pasan a la operación



• Paso 3b: Identificar las interfaces apropiadas para cada componente.– En el contexto del diseño a nivel de componentes, una

interfaz UML es un grupo de operaciones externamente visibles (i.e públicas).

– La interfaz no contiene estructura interna; no tiene atributos ni asociaciones.

– Formalmente una interfaz es el equivalente a una clase abstracta que proporciona una conexión controlada entre las clases de diseño.

– En esencia, las operaciones definidas para la clase de diseño están orientadas en una o más clases abstractas

– Cada operación dentro de la interfaz debe tener cohesión, es decir, debe mostrar procesamiento que se concentra en una función o sub función limitada.



Trabajo Imprenta

Nº de páginasNº de ladosTipo Papel Peso papel tamaño papel color papelAmpliaciónRequisitos ColorCaracterísticas producción Opciones distribución Opciones encuadernado portadas Almacén refine prioridad

Calcular costo página()Calcular costo trabajo()Imprimir y pasar trabajo()Calcular costo trabajo total()Revisar prioridad()Pasar trabajo a producción()

<<Interfaz>>Iniciar trabajo

ConstruirOrdenTrabajo()VerificarPrioridad()PasarTrabajoaProducción()

<<Interfaz>>calcular costo trabajo

CalcularCostoPagina()CalcularCostoPapel()CalcularCostoProd()CalcularCostoTrabajoTotal()



Imprimirtrabajo

Trabajo Producción

OrdenTrabajo

Atributos apropiados

ConstruirOrdenTrabajo()

ColaTrabajo

Atributos apropiados

revisarPrioridad()

<<Interfaz>>Iniciar Trabajo

pasarTrabajoaProduccion()

CalcularTrabajo

InicarTrabajo

ConstruirTrabajo

RemitirTrabajo

ObtenerDescripciónTrabajo



• Paso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos.– En general, las estructuras y los tipos de datos con que

se describen atributos se definen dentro del contexto del lenguaje de programación que habrá de usarse para la implementación.

– La sintaxis usada por UML para definir un tipo de datos es la siguiente

Nombre: tipo-Expresión = valor-inicial {propiedad cadena}Nombre: corresponde al nombre del atributotipo-Expresión: es el tipo de datosvalor-inicial: Valor que toma el objeto cuando es creado{propiedad cadena}: define una propiedad o característica del atributo



• Paso 3c: Elaborar atributos y definir los tipos y las estructuras de datos necesarios para implementarlos.– Ejemplo: en las primeras iteraciones los atributos

suelen describirse por nombre, sin embargo, a medida que avanza la elaboración del diseño, cada atributo se define empleando el formato de atributos UML

Tipo-pesopapel: string = “A”{contiene 1 de 4 valores: A, B, C o D}

– Si un atributo aparece varías veces en varias clases de diseño, y tiene una estructura relativamente compleja, es mejor crear una clase separada para acomodar el atributo.



• Paso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación.– Esto se logra utilizando un pseudo código basado en un

lenguaje de programación o el diagrama de actividad de UML.

– Cada componente de SW se elabora mediante varias interacciones que aplican el concepto de refinamiento paso a paso.

– La primera iteración define cada operación como parte de la clase de diseño. En cada caso, la operación debe estar caracterizada de manera que asegure una cohesión elevada, es decir, la operación debe realizar una sola función o sustitución definida.



• Paso 3-D: Describir de manera detallada el flujo de procesamiento dentro de cada operación.– La siguiente iteración hace poco más que expandir el

nombre de la operación– Por Ejemplo: la operación calcularcostoPapel() se expandiría

de la siguiente forma:CalcularCostoPapel(peso, tamaño, color):numérico

– Esto significa que la operación CalcularCostoPapel() requiere los atributos peso, tamaño y color como entrada y devuelve un valor numérico como salida.

– Si el algoritmo requerido para implementar CalcularCostoPapel() es simple y se comprende ampliamente, tal vez sea innecesario elaborar diseño adicional


Valida entrada de atributos

Accesar BDPapel(peso)

CostoPapelPorPagina = CostoBasePorPágina

CostoPapelPorPagina =CostoBasePorPagina * 1.2

CostoPapelPorPagina = CostobasePorPagina * 1.4

CostoPapelPorpagina =CostoBasePorPagina * 1.6

CostoPapelPorPagina =costoBasePorPágina * 1.14

Devuelve(CostoPapelPorPagina)

Regresa a costoPapelPorPagina

Tamaño = B

Tamaño = C

Tamaño = D

El color espersonalizado

El color es estandar




• Paso 4: Describir fuentes de datos persistentes (bases de datos y archivos) e identificar las clases necesarias para manejarlas.

• Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente.– Al comportamiento dinámico de un objeto lo afectan eventos

externos y estado actual del objeto.– Para comprender el comportamiento dinámico de un objeto,

el diseñador debe examinar todos los casos de uso relevantes durante el periodo de vida de la clase diseño.

– Estos casos de uso proporcionan información que ayuda al diseñador a delinear los eventos que afectan al objeto y a los estados en que reside éste mientras pasa el tiempo y ocurren eventos.



• Paso 5: Desarrollar y elaborar representaciones del comportamiento de una clase o un componente.– La transición entre estados (impulsados por los eventos) se

representa empleando un diagrama de estados de UML.– El evento que gatilla la transición de un estado a otro toma

la siguiente forma:

Nombre-evento {lista parámetros} [condición de guardia] / expresión de acción.

– Nombre-evento: identifica el evento.– Lista-parámetros: incorpora datos asociados con el evento.– Condición-guardia: está escrita en lenguaje de restricción de

objetos (OCL). Y especifica una condición que debe cumplirse antes de que pueda ocurrir el evento.

– Expresión de acción: define una acción antes de que ocurra cuando tenga lugar la transición.



Construir datos trabajoEntrar/leerDatosTrabajo()

Salir/desplegarDatosTrabajo()Hacer/revisarCosistencia()

Incluir/entradaDatos

Calcular Costo TrabajoEntrar/calcularTrabajo

Salir/guardarcostoTotalTrabajo()

Formar trabajoEntrar/ConstruirTrabajo()Salir/guardarNumeroOT()

Hacer/

Remitir trabajoEntrar/remitirTrabajo()Salir/iniciarTrabajo()

Hacer/colocar en ColaTrabajo

EntradaDatosIncompletos

entradaDatosCompletada [todos los elementos de datos consistentes]/desplegarOpcionesUsuario

costoTrabajoAceptado [el cliente está autorizado] / obetenerFirmaElectrónica

fechaEntregaAceptada [el cliente está autorizado] / estimadoTrabajoImpresión

trabajoRemitido [todas las autorizaciones adquiridas] / imprimirOrdenTrabajo

Comportamiento dentro del estado ConstuirDatosTrabajo



• Paso 6: Elaborar diagramas de despliegue para proporcionar detalles de la implementación adicional.– Se elaboran diagramas de despliegue para representar la

ubicación de paquetes clave de componentes. Sin embargo, por lo general los componentes de representan individualmente dentro de un diagrama de componente. La razón de esto es evitar la complejidad del diagrama.

• Paso 7: Factorizar todas las representaciones del diseño al nivel de componentes y siempre deben considerarse alternativas– El primer modelo a nivel de componente que se cree no será

tan completo, consistente o exacto como la enésima iteración que aplique al modelo. Es esencial usar refactorización mientras se realiza el trabajo de diseño.


4. Lenguajes de restricción de Objetos

• La variedad de diagramas disponible como parte de UML proporciona a un diseñador un rico conjunto de formas de representación para el modelo de diseño. Sin embargo, las representaciones gráficas no suelen bastar.

• El diseñador necesita de un mecanismo para representar explicita y formalmente la información que restringe algún elemento del modelo de diseño.

• Es posible, describir las restricciones en lenguaje natural, pero este método lleva invariablemente a la inconsistencia y la ambigüedad, por lo que lo apropiado parece un lenguaje formal que tome en cuenta la teoría de conjunto y los lenguajes formales de especificación, pero que tenga una cantidad menor de sintaxis matemáticas que un lenguaje de programación.


• El lenguajes de restricción de Objetos (OCL) complementa al UML al permitir que un ingeniero de SW use gramática y sintaxis formales para construir instrucciones sin ambigüedades relacionadas con varios elementos del modelo de diseño.

• En OCL las instrucciones se construyen en 4 partes:1. Un contexto que define la situación limitada en que es

válida la instrucción.

2. Una propiedad que representan algunas características del contexto.

3. Una operación que manipula o califica una propiedad

4. Palabras clave (como if, then, else, and, or, not, implies) con que se especifican expresiones condicionales.



• Ejemplo: considere la condición de guardia colocada en el evento costoTrabajoAceptado que causa una transición entre los estados calcularCostoTrabajo() y formarTrabajo() dentro del diagrama de gráfica de estado para la clase TrabajoImprenta.

• En el diagrama, la condición guardia se expresa en lenguaje natural y especifica que la autorización sólo se presentará si el cliente está autorizado para aprobar el costo del trabajo.

Clientetiene.autoridadAutorización = “si”

• Donde un atributo booleano, autoridadAutorización, de la clase CLIENTE (una instancia específica de la clase) debe tener el valor si para satisfacer la condición guardia.



• Cuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño.

• El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal.




• Cuando se crea el modelo de diseño suele haber instancias en que deben satisfacerse las condiciones previas y posteriores antes de completar alguna opción especificada en el diseño.

• El OCL proporciona una herramienta poderosa para especificar condiciones previas y posteriores de manera formal.

• Ej: al sistema de la imprenta, el cliente ahora proporciona un límite de costo superior para el trabajo de impresión y una fecha de entrega límite, al mismo tiempo que se especifican otras características de trabajo. Si el costo y la entrega estimada exceden esos límites, el trabajo no se entregará y debe notificarse al cliente.


Context TrabajoImprenta::validate(limiteSuperiorCosto : Integer, reqEnvioCliente : Integer)

pre: LimiteSuperiorCosto > 0 and reqEnvioCliente > 0 and tiene.autorizacionTrabajo = “no” post: if tiene.costoTotalTrabajo <=

limiteSuperiorCosto and tiene.fechaEnvio <= reqEnvioCliente then tiene.autorizacionTrabajo = “si” endif

diseño e implementación

Documents