Unidad 4: Diseño orientado a objetos.

Patrones de diseño.

El diseño orientado a objetos es una etapa fundamental en el desarrollo de sistemas orientados a objetos, sin embargo, por lo general, en la práctica se observa que no se le dedica el tiempo suficiente o bien es efectuada de una manera muy superficial. Es común observar una pequeña etapa de análisis de requisitos y un pasaje inmediato al proceso de programación.Algunas veces para justificar esta superficialidad en cuanto a la manera de trabajar en la etapa de diseño, se atribuye a la falta de tiempo como causa principal. Sin embargo, sería más que beneficioso aplicar las buenas prácticas en cuanto a desarrollo de software para lograr productos de calidad.Particularmente, durante la etapa de diseño se efectúan decisiones relativas a qué métodos se requerirán, dónde se los colocarán y cómo deberían interactuar los objetos, actividades nada triviales y muy importantes. Por tal motivo, sería altamente conveniente tener en cuenta algunos patrones de diseño fundamentales.En la tecnología de objetos, un patrón es una descripción del problema y la solución, a la que se da un nombre, y que se puede aplicar a nuevos contextos; idealmente, proporciona consejos sobre el modo de aplicarlo en varias circunstancias, y considera los puntos fuertes y compromisos.

Componentes.

El componente básico del OSM es la clase de objetos.

Se distinguen tres tipos de clases:

·         Objetos Entidad
·         Objetos de Interfaz
·         Objetos de Control.

Para cada clase identificada se describen:

·         Operaciones
·         Atributos
·         Restricciones

Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se distinguen los siguientes tipos de asociaciones:

·         Relaciones Estáticas
·         Herencia
·         Agregación
·         Comunicación por mensajes.

Diseño de interfaz de sistema.

El diseño de interfaces de usuario es una tarea que ha adquirido relevancia en el desarrollo de un sistema. La calidad de la interfaz de usuario puede ser uno de los motivos que conduzca a un sistema al éxito o al fracaso. Los principios que se presentan son de utilidad para creación de interfaces funcionales y de fácil operación. A pesar de no ser capaces de resolver todos los aspectos propios del contexto con el que se esté trabajando, pueden ser combinados con la prototipación y la aplicación de heurísticas de evaluación para facilitar el proceso de diseño.
Si la IU está bien diseñada, el usuario encontrará la respuesta que espera a su acción. Si no es así puede ser frustrante su operación, ya que el usuario habitualmente tiende a culparse a sí mismo por no saber usar el objeto.
Los programas son usados por usuarios con distintos niveles de conocimientos, desde principiantes hasta expertos. Es por ello que no existe una interfaz válida para todos los usuarios y todas las tareas. Debe permitirse libertad al usuario para que elija el modo de interacción que más se adecúe a sus objetivos en cada momento. La mayoría de los programas y sistemas operativos ofrecen varias formas de interacción al usuario.
Existen tres puntos de vista distintos en una IU: el del usuario, el del programador y el del diseñador (analogía de la construcción de una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los conceptos y expectativas acerca de la misma, desarrollados a través de su experiencia.
El modelo permite explicar o predecir comportamientos del sistema y tomar las decisiones adecuadas para modificar el mismo. Los modelos subyacen en la interacción con las computadoras, de ahí su importancia.

Notación de diseño.

La notación de diseño, junto con los conceptos de programación estructurada, permite al diseñador representar detalles procedimentales de manera que se facilite la traducción a código. Hay disponibles notaciones gráficas, tabulares y de texto.   


Gráfica del diseño.

Es incuestionable que las herramientas gráficas, tales como los diagramas de flujo o diagramas de caja, proporcionan una excelente forma gráfica que describen muy bien el detalle procedimental. Sin embargo, si se emplean mal las herramientas gráficas, una imagen incorrecta puede conducir a un software erróneo. El diagrama de flujo es un gráfico muy sencillo. Se usa una caja (cuadro/rectángulo) para indicar un paso del proceso. Un rombo representa una condición lógica y las flechas indican el flujo de control.

Notación tabular del diseño.

Las tablas de decisión proporcionan una notación de procedimientos a una forma tabular. Es difícil que la tabla se pueda interpretar mal, e incluso puede usarse como entrada interpretable por la máquina para un algoritmo manejado por tabla. La tabla se divide en cuatro secciones el cuadrante superior izquierdo contiene una lista de todas las condiciones. El cuadrante inferior izquierdo contiene una lista de todas las acciones posibles basándose en combinaciones de las condiciones. Los cuadrantes de la derecha forman una matriz que indican las combinaciones de las condiciones y las correspondientes acciones que se han de producir para cada combinación específica. Por lo tanto, cada columna de la matriz puede interpretarse como una regla de procesamiento.

Mediciones de los atributos del diseño.

La medición del software en las primeras etapas del ciclo de vida resulta insatisfactoria debido a las deficiencias que presentan las métricas y los sistemas predictivos existentes, en este trabajo se parte de la utilización de una metodología formalizada, que permite definir dos métricas que son validas desde el punto de vista teórico.Se construye un sistema predictivo premacov que permite predecir los valores de macov a partir del análisis del correspondiente diagrama de flujo de datos expandido.Se incluye también la validación de premacov según la teoría de la medición, así como un análisis de su aplicación practica mediante la recogida de valores en trabajos de alumnos y en dos aplicaciones profesionales de gestión.Este sistema predictivo es un medio de control de la consistencia entre el análisis y el diseño de un sistema software.

Métricas del diseño.

Permiten medir de forma cuantitativa la calidad de los atributos internos del software. Esto permite al ingeniero evaluar la calidad durante el desarrollo del sistema.

Análisis formal del diseño.

En la actualidad la mayoría de los usuarios de microcomputadoras tienen acceso a un sistema de información o forman parte del mismo. Todas las organizaciones cuentan con un sistema de información de algún tipo, que sus empleados deben utilizar. Cuando en cualquier organización se desea implantar un nuevo sistema, de tal forma que sus miembros sean más productivos, obteniendo un mayor provecho y apoyo del mismo, se requiere realizar una serie de acciones y previsiones.La creación o establecimiento de un nuevo sistema de información en la organización, puede ser una tarea compleja. Para encarar este tipo de situaciones existe un proceso de análisis y diseño de sistemas que auxilia en la resolución de tales problemas. El análisis y diseño de sistemas proporciona una guía útil que busca disminuir las situaciones de fracaso o errores al acometer estos procesos.

Razones para conocer el análisis y diseño de sistemas


Aunque pareciese que es tema sólo de profesionales, como usuario final, toda persona que usa una microcomputadora se beneficiará al conocer sobre este proceso. Puede ocurrir que, una vez contratado como miembro de una organización, se convierta en usuario de su sistema de información, entonces el conocimiento del análisis y diseño de sistemas, le permitirá aumentar su productividad personal, sirviéndole para resolver los problemas que surjan en su área de trabajo, determinando nuevos requerimientos de información y permitiéndole colaborar con los profesionales en informática en la resolución de tales situaciones.


Necesidad del análisis y diseño de sistemas

La instalación de un sistema sin la adecuada planeación puede conducir a grandes frustraciones y causar que el sistema sea subutilizado, o peor aún, deje de ser usado al no cumplir con las expectativas que le dieron origen. El análisis y diseño de sistemas es una guía que permite estructurar el proceso de desarrollo de sistemas de información. Tal proceso siempre representará un esfuerzo, inversión de tiempo y recursos por parte de la organización. Acometer tal esfuerzo de manera casual, presenta un alto grado de riesgo al no garantizar la culminación del proyecto con éxito. Este procedimiento permite reducir al mínimo el riesgo de fracaso de nuevos proyectos, pues es común que muchos errores surjan al utilizar nuevos sistemas de información, bien por no adaptarse correctamente a las necesidades reales o por desempeñarse de forma inadecuada.

Técnicas de reingeniería e ingeniería de reverso

La Reingeniería de Procesos es una técnica en virtud de la cual se analiza en profundidad el funcionamiento de uno o varios procesos dentro de una empresa con el fin de rediseñarlos por completo y mejorar radicalmente el funcionamiento de la organización en su conjunto.
La Reingeniería surge como respuesta a las ineficiencias propias de la organización funcional en las empresas y sigue un método estructurado consistente en:

·         Identificar los procesos clave de la empresa.
·         Asignar responsabilidad sobre dichos procesos a un "propietario".
·         Definir los límites del proceso.
·         Medir el funcionamiento del proceso.
·         Rediseñar el proceso para mejorar su funcionamiento.

Un proceso es un conjunto de actividades organizadas para conseguir un fin, desde la producción de un objeto o prestación de un servicio hasta la realización de cualquier actividad interna (por ejemplo, la elaboración de una factura). Los objetivos clave del negocio dependen de procesos de negocio interfuncionales eficaces, y, sin embargo, estos procesos comúnmente no se gestionan. El resultado es que los procesos de negocio se convierten en ineficaces e ineficientes, lo que hace necesario adoptar un método de gestión por procesos.
Durante muchos años, casi todas las organizaciones empresariales se han organizado verticalmente, por funciones. Actualmente, la organización por procesos permite prestar más atención a la satisfacción del cliente, mediante una gestión integral eficaz y eficiente: se produce la transición del sistema de gestión funcional al sistema de gestión por procesos.
Es en este nuevo contexto de gestión, y para lograr una correcta implementación de los procesos diseñados, que entran en juego las técnicas de las que se vale la Reingeniería de Procesos para realizar la reestructuración de la empresa.
Las mencionadas técnicas, que se describen y analizan a continuación, son:

·         Just In Time (o Justo a Tiempo)
·         Gestión de Calidad Total (o TQM – Total Quality Management)
·         Benchmarking
·         Outsourcing (o Tercerización)
·         Análisis de Valor.

El objetivo de la ingeniería inversa es obtener información o un diseño a partir de un producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado.Los productos más comúnmente sometidos a ingeniería inversa son los programas de computadoras y los componentes electrónicos, pero, en realidad, cualquier producto puede ser objeto de un análisis de Ingeniería Inversa.
El método se denomina así porque avanza en dirección opuesta a las tareas habituales de ingeniería, que consisten en utilizar datos técnicos para elaborar un producto determinado. En general, si el producto u otro material que fue sometido a la ingeniería inversa fue obtenido en forma apropiada, entonces el proceso es legítimo y legal. De la misma forma, pueden fabricarse y distribuirse, legalmente, los productos genéricos creados a partir de la información obtenida de la ingeniería inversa, como es el caso de algunos proyectos de Software libre ampliamente conocidos.
El programa Samba es un claro ejemplo de ingeniería inversa, dado que permite a sistemas operativos UNIX compartir archivos con sistemas Microsoft Windows. El proyecto Samba tuvo que investigar información confidencial (no liberada al público en general por Microsoft) sobre los aspectos técnicos relacionados con el sistema de archivos Windows. Lo mismo realiza el proyecto WINE para el conjunto de API de Windows y OpenOffice.org con los formatos propios de Microsoft Office, o se hace para entender la estructura del sistema de archivos NTFS y así poder desarrollar drivers para la lectura-escritura sobre el mismo (principalmente para sistemas basados en GNU/Linux).
La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender, modificar y mejorar dicho modo de funcionamiento.Pero este término no sólo se aplica al software, sino que también se considera ingeniería inversa el estudio de todo tipo de elementos (por ejemplo, equipos electrónicos, micro controlador, u objeto fabril de cualquier clase). Diríamos, más bien, que la ingeniería inversa antecede al nacimiento del software, tratándose de una posibilidad a disposición de las empresas para la producción de bienes mediante copiado¹ desde el mismo surgimiento de la ingeniería.
En el caso concreto del software, se conoce por ingeniería inversa a la actividad que se ocupa de descubrir cómo funciona un programa, función o característica de cuyo código fuente no se dispone, hasta el punto de poder modificar ese código o generar código propio que cumpla las mismas funciones. La gran mayoría del software de pago incluye en su licencia una prohibición expresa de aplicar ingeniería inversa a su código, con el intento de evitar que se pueda modificar su código y que así los usuarios tengan que pagar si quieren usarlo.
La ingeniería inversa nace en el transcurso de la Segunda Guerra Mundial, cuando los ejércitos enemigos incautaban insumos de guerra como aviones u otra maquinaria de guerra para mejorar las suyas mediante un exhaustivo análisis.

Estándares de calidad.

Un estándar se define como el grado de cumplimiento exigible a un criterio de calidad. Dicho en otros términos, define el rango en el que resulta aceptable el nivel de calidad que se alcanza en un determinado proceso. Los estándares de calidad determinan el nivel mínimo y máximo aceptable para un indicador. Si el valor del indicador se encuentra dentro del rango significa que estamos cumpliendo con el criterio de calidad que habíamos definido y que las cosas transcurren conforme a lo previsto. Estamos cumpliendo con nuestro objetivo de calidad. Si, por el contrario, estamos por debajo del rango significa que no cumplimos nuestro compromiso de calidad y deberemos actuar en consecuencia (o bien la apuesta fue demasiado optimista para los medios disponibles). Por el contrario, si estamos por encima, o bien tendremos que redefinir el criterio o, desde luego, estamos gastando (en términos de esfuerzo) más de lo que pensábamos que era necesario (o fuimos pesimistas para fijar el rango o pecamos de inexpertos). El estándar, por consiguiente, determina el mínimo nivel que comprometería la calidad de ese proceso. Por debajo del estándar la práctica (producto o servicio) no reúne calidad suficiente. Una observación que no debe olvidarse es que los estándares no deben ser nunca del 100% en razón de que siempre sucederán imprevistos que impedirán tal cumplimiento. Además, cualquier auditor de calidad sospechará de que un estándar se logre al 100% una y otra vez, o que se supere año tras año. Esto normalmente solo indica que no estaban adecuadamente definidos.


Herramientas case.


Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.   

Integrantes:


Ascanio, Maryeling.
Chouza, Jose.
Prado, Williana.
Torrealba, Anadilis.

 PNF. Informática, sección 4 (Nocturno).