Powered By Blogger

martes, 3 de julio de 2012

DISEÑO ORIENTADO A OBJETOS


Diseño orientado a objeto
     Patrones de diseño, componentes, diseño de interfases del sistema, notación de diseño.
LLos patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces. Un patrón de diseño es una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

   El componente básico del diseño orientado a objetos 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

  El diseño de interfaces de sistema 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. El presente artículo se centra en los componentes de software de las interfaces de usuario, quedando fuera del alcance de mismo otros aspectos, como hardware y documentación. Lo anteriormente expuesto se complementa con un caso práctico de diseño de interfaces de usuario, producto de realizar la actividad de "Definición de Interfaces de Usuario" (EFS 4) de la metodología Métrica Versión 2.
  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.


     Medición de los atributos del diseño.
L  la  medicion del software en las primeras etapas del ciclo de vida resulta insatisfactoria debido a las deficiencias que presentan las metricas y los sistemas predictivos existentes, en este trabajo se parte de la utilizacion de una metodologia formalizada, que permite definir dos metricas macov que son validas desde el punto de vista teorico.
    se  construye un sistema predictivo premacov que permite predecir los los valores de macov a partir del analisis del correspondiente diagrama de flujo de datos expandido. incluye tambien la validacion de premacov segun la teoria de la medicion, asi como un analisis de su aplicacion practica mediante la recogida de valores en trabajos de alumnos y en dos aplicaciones profesionales de gestion.

      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.
L las métricas se centran en cuantificar tanto la complejidad, como la funcionalidad y eficiencia inmersa en el desarrollo de software. Inclina sus objetivos a mejorar la comprensión de la calidad del producto, a estimar la efectividad del proceso y mejorar la calidad del trabajo.
   las métricas empleadas están diseñadas para evaluar los siguientes atributos de calidad:
§  Responsabilidad . Consiste en la responsabilidad asignada a una clase en un marco de modelado de un dominio o concepto, de la problemática propuesta.
§  Complejidad de implementación. Consiste en el grado de dificultad que tiene implementado un diseño de clases determinado.
§  Reutilización. Consiste en el grado de reutilización presente en una clase o estructura de clase,dentro de un diseño de software.
§  Acoplamiento. Consiste en el grado de dependencia o interconexión de una clase o estructura de clase, con otras, está muy ligada a la característica de Reutilización.
§  Complejidad del mantenimiento. Consiste en el grado de esfuerzo necesario a realizar para desarrollar un arreglo, una mejora o una rectificación de algún error de un diseño de software. Puede influir indirecta, pero fuertemente en los costes y la planificación del proyecto.

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

Reingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.”
Entre la técnicas de Reingeniería tenemos:

Reestructuración de Datos: Esto es reversar el modelo físico al modelo lógico para obtener el modelo de E-R de la base de datos, recuperando el diccionario de datos, atributos, entidades, dominios, cardinalidad etc, la mayoría de las herramientas CASE del mercado cumplen con esta función.

Reestructuración de Código: Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de reestructuración, de no tener el código fuente disponible puede aplicarse ingeniería inversa sobre el compilado para obtener el código fuente original siempre y cuando la licencia del software lo permita, inmediatamente se indican las violaciones de las estructuras de programación estructurada u orientada a objetos, y entonces se reestructura el código (esto se puede hacer automáticamente). El código reestructurado resultante se revisa y se comprueba para asegurar que no se hayan introducido anomalías. Se actualiza la documentación interna del código.
§  Responsabilidad . Consiste en la responsabilidad asignada a una clase en un marco de modelado de un dominio o concepto, de la problemática propuesta.
§  Complejidad de implementación. Consiste en el grado de dificultad que tiene implementado un diseño de clases determinado.
§  Reutilización. Consiste en el grado de reutilización presente en una clase o estructura de clase,dentro de un diseño de software.
§  Acoplamiento. Consiste en el grado de dependencia o interconexión de una clase o estructura de clase, con otras, está muy ligada a la característica de Reutilización.
§  Complejidad del mantenimiento. Consiste en el grado de esfuerzo necesario a realizar para desarrollar un arreglo, una mejora o una rectificación de algún error de un diseño de software. Puede influir indirecta, pero fuertemente en los costes y la planificación del proyecto.


     Estándares de calidad.
Son normas y protocolos internacionales que deben cumplir productos de cualquier indole para su distribución y consumo por el cliente final.

Herramientas case.

Son diversas aplicaciones informáticasdestinadas 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).









martes, 6 de marzo de 2012

ANÁLISIS DE REQUERIMIENTOS

INSPECCIÓN

Según Presuman, en su libro “Ingeniería de Software, un enfoque practico” (1998)”

“La inspección también es conocida como revisión técnica formal, y es el punto de vista mas efectivo desde el punto de vista de aseguramiento de calidad, y es dirigida por los ingenieros de software u otras personas. Para los ingenieros la inspección es un medio efectivo para descubrir errores y mejorar la calidad del software” (p.165)

VALIDACIÓN

Es el proceso de control que asegura que el software cumple con su especificación y satisface las necesidades del usuario Muchas veces se confunde “verificación” con validación”. Boehm (1979) puso en claro con pocas palabras la diferencia: • Validación: ¿Estamos construyendo el producto correcto? Se ocupa de controlar si el producto satisface los requerimientos del usuario • Verificación: ¿Estamos construyendo correctamente el producto? implica controlar que el producto conforma su especificación inicial.

En este punto es necesario recordar que la SRS debe estar libre de errores, por lo tanto, la validación garantiza que todos los requerimientos presentes en el documento de especificación sigan los estándares de calidad.

No debe confundirse la actividad de evaluación de requerimientos con la validación de requerimientos. La evaluación verifica las propiedades de cada requerimiento, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos.

Durante la actividad de validación pueden hacerse preguntas en base a cada una de las características que se desean revisar. A continuación se presentan varios ejemplos:

  • ¿Están incluidas todas las funciones requeridas por el cliente? (completa)
  • ¿Existen conflictos en los requerimientos? (consistencia)
  • ¿Tiene alguno de los requerimientos más de una interpretación? (no ambigua)
  • ¿Está cada requerimiento claramente representado? (entendible)
  • ¿Pueden los requerimientos ser implementados con la tecnología y el presupuesto disponible? (factible)
  • ¿Está la SRS escrita en un lenguaje apropiado? (clara)
  • ¿Existe facilidad para hacer cambios en los requerimientos? (modificable)
  • ¿Está claramente definido el origen de cada requisito? (rastreable)
  • ¿Pueden los requerimientos ser sometidos a medidas cuantitativas? (verificable)



DETECCION DE CONFLICTOS

La detección de conflictos es una herramienta analítica que automatiza el proceso de detección de conflictos. ProjectWise Schedule Simulation permite identificar grupos de elementos comerciales o gráficos y detectar conflictos geométricos entres este grupo de elementos objeto. Después puede revisar interactiva y gráficamente estos conflictos. Las reglas de supresión se pueden aplicar para identificar conflictos que no deben ser informados. Los ajustes asociados con los conflictos de ejecución se administran y siguen como un trabajo de conflicto. Un trabajo es un contenedor de criterios, de reglas y resultados, que se configuran y guardan en el archivo activo para su reutilización. Un trabajo se pueden almacenar en una biblioteca DGN. Un trabajo se puede definir y procesar en archivo sólo de lectura, pero la definición y los resultados del trabajo no pueden ser almacenados.

DOCUMENTOS DE REQUERIMIENTOS DE SOFTWARE

Es la declaración oficial de lo que es requerido para que el sistema sea desarrollado. Incluye la definición y especificación de requerimientos. No es un documento de diseño. Tanto como sea
posible, es un conjunto de lo que es el sistema y como lo hará.

- CREACIÓN USOS E IMPORTANCIA

El proceso de creación de software puede llegar a ser muy complejo, dependiendo de su porte, características y criticidad del mismo. Por ejemplo la creación de un sistema operativo es una tarea que requiere proyecto, gestión, numerosos recursos y todo un equipo disciplinado de trabajo. En el otro extremo, si se trata de un sencillo programa (por ejemplo, la resolución de una ecuación de segundo orden), éste puede ser realizado por un solo programador (incluso aficionado) fácilmente. Es así que normalmente se dividen en tres categorías según su tamaño (líneas de código) o costo: de «pequeño», «mediano» y «gran porte». Existen varias metodologías para estimarlo, una de las más populares es el sistema COCOMO que provee métodos y un software (programa) que calcula y provee una aproximación de todos los costos de producción en un «proyecto software» (relación horas/hombre, costo monetario, cantidad de líneas fuente de acuerdo a lenguaje usado, etc.).

Considerando los de gran porte, es necesario realizar complejas tareas, tanto técnicas como de gerencia, una fuerte gestión y análisis diversos (entre otras cosas), la complejidad de ello ha llevado a que desarrolle una ingeniería específica para tratar su estudio y realización: es conocida como Ingeniería de Software.

A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras.

Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema.

Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.

jueves, 9 de febrero de 2012

ESPECIFICACIÓN DE REQUERIMIENTOS

TEXTUAL, NOTACIÓN GRÁFICA Y LENGUAJES DE REPRESENTACIÓN (LENGUAJE UNIFICADO DE MODELADO UML), NOTACIÓN DE REQUERIMIENTOS DE USUARIO URN.

El termino requerimiento no se utiliza de forma consistente en la industria del software. En algunos casos, un requerimiento se visualiza como una declaración abstracta de alto nivel de un servicio que debe proveer el sistema o como una restricción de éste. Por otro lado, es una definición matemática detallada y formal de una función del sistema
Lenguaje de Modelado Unificado (UML)

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. [Enciclopedia Online Wikipedia, 2008c]

Es importante resaltar que UML es un "lenguaje" para especificar y no para describir métodos o procesos. Se utiliza para definir un sistema de software, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en una gran variedad de formas para dar soporte a una metodología de desarrollo de software, pero no especifica en sí mismo qué metodología o proceso usar.

Los requerimientos deusuario son para el usode la gente relacionadacon la utilización yobtención del sistema.Debe ser redactada conun lenguaje natural con diagramas y tablas

TECNICAS PARA ESCRIBIR REQUERIMIENTOS DE ALTA CALIDAD. ESTANDARES DE DOCUMENTACIÓN

Una buena documentación es esencial para lograr un diseño correcto y un mantenimiento eficiente de los sistemas digitales. Además de ser precisa y completa, la documentación debe ser algo instructiva, de modo que un ingeniero de pruebas, técnico de mantenimiento, o inclusive el ingeniero de diseño original (seis meses después de diseñar el circuito), pueda averiguar como funciona el sistema con solo leer la documentación.

Aunque el tipo de documentación depende de la complejidad del sistema y los entornos en los que se realizan el diseño y la fabricación, un paquete de documentación debe contener (por regla general) al menos los siguientes seis elementos:

1.Una especificación de circuito que se describe exactamente lo que se supone debe hacer el circuito o sistema, incluyendo una descripción de todas las entradas y las salidas (“interfaces”) y las funciones que se van a realizar. Advierta que las “especificaciones” no tienen que especificar como consigue el sistema sus resultados, sino únicamente que resultados genera.

2. Un diagrama de bloques es una descripción pictórica e informal de los principales módulos funcionales del sistema y sus interconexiones básicas.

3. Un diagrama esquemático es una especificación formal de los componentes eléctricos del sistema, sus interconexiones y todos los detalles necesarios para construir el sistema, incluyendo los tipos de CI, indicadores de referencia y números terminales. Se suelen utilizar el término diagrama lógico para referirse a un dibujo informal que no tiene este nivel de detalle. La mayoría de los programas para edición de esquemáticos tiene la capacidad de generar en cuenta de materiales a partir del diagrama esquemático.

4. Un diagrama de temporización muestra los valores de diversas señales lógicas en función del tiempo, incluyendo los retardos, entre causa y efecto, de las señales críticas.

5. Una descripción de dispositivo de lógica estructurada que indica la función interna de un PLD, FPGA o ASIC. Normalmente esta descripción se describe en un lenguaje de descripción hardware (HDL) tal como VHDL O ABEL, pero puede estar en forma de ecuaciones lógicas, tablas de estado o diagramas de estado. En algunos casos se pueden utilizar un lenguaje de programación convencional, como C, para modelar el funcionamiento de un circuito o para especificar su comportamiento.

6. Una descripción del circuito en un documento de texto narrativo que, junto con el resto de la documentación, explica como funciona internamente el circuito. En el caso de que la maquina de estado debe describirse mediante tablas de estado, diagramas de estado, lista de transiciones o archivo de texto en un lenguaje de descripción de maquinas de estado como ABEL o VHDL. La descripción del circuito debe incluir cualquier suposición y cualquier fallo potencial en el diseño y operación del circuito, también debe señalar el uso de cualquier “truco” de diseño que no sea obvio. Una buena descripción de circuito también contiene definiciones de acrónimos y otros términos especializados y tiene referencias o documentos relacionados.


TIPOS DE REQUERIMIENTOS


Requerimientos funcionales

Son declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas particulares. En algunos casos, los requerimientos funcionales de los sistemas también declaran explícitamente lo que el sistema no debe hacer.

Los requerimientos funcionales de un sistema describen la funcionalidad o los servicios que se espera que éste provea. Estos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software. Cuando se expresan como requerimientos del usuario, habitualmente se describen de forma general mientras que los requerimientos funcionales del sistema describen con detalle la función de éste, sus entradas y salidas, excepciones, etc.

Muchos de los problemas de la ingeniería de software provienen de la imprecisión en la especificación de requerimientos. Para un desarrollador de sistemas es natural dar interpretaciones de un requerimiento ambiguo con el fin de simplificar su implementación. Sin embargo, a menudo no es lo que el cliente desea. Se tienen que estipular nuevos requerimientos y se deben hacer cambios al sistema, retrasando la entrega de éste e incrementando el costo.

En principio, la especificación de requerimientos funcionales de un sistema debe estar completa y ser consistente. La compleción significa que todos los servicios solicitados por el usuario están definidos. La consistencia significa que los requerimientos no tienen definiciones contradictorias. En la práctica, para sistemas grandes y complejos, es imposible cumplir los requerimientos de consistencia y compleción. La razón de esto se debe parcialmente a la complejidad inherente del sistema y parcialmente a que los diferentes puntos de vista tienen necesidades inconsistentes. Estas inconsistencias son obvias cuando los requerimientos se especifican por primera vez. Los problemas emergen después de un análisis profundo. Una vez que éstos se hayan descubierto en las diferentes revisiones o en las fases posteriores del ciclo de vida, se deben corregir en el documento de requerimientos.

Requerimientos no funcionales

Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo, estándares, etc.

Son aquellos requerimientos que no se refieren directamente a las funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. De forma alternativa, definen las restricciones del sistema como la capacidad de los dispositivos de entrada/salida y la representación de datos que se utiliza en la interface del sistema.

Muchos requerimientos no funcionales se refieren al sistema como un todo más que a rasgos particulares del mismo. Esto significa que a menudo con más críticos que los requerimientos funcionales particulares. Mientras que el incumplimiento de este último degradará el sistema, una falla en un requerimiento no funcional del sistema lo inutiliza.

Los requerimientos no funcionales surgen de la necesidad del usuario, debido a las restricciones en el presupuesto, a las políticas de la organización, a la necesidad de interoperabilidad con otros sistemas de software o hardware o a factores externos como los reglamentos de seguridad, las políticas de privacidad, etcétera.

Estos diferentes tipos de requerimientos se clasifican de acuerdo con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del producto; como los requerimientos de desempeño en la rapidez de ejecución del sistema y cuánta memoria se requiere; los de fiabilidad que fijan la tasa de fallas para que el sistema sea aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y procedimientos existentes en la organización del cliente y en la del desarrollador: estándares en los procesos que deben utilizarse; requerimientos de implementación como los lenguajes de programación o el método de diseño a utilizar, y los requerimientos de entrega que especifican cuándo se entregará el producto y su documentación.

• Requerimientos externos. Se derivan de los factores externos al sistema y de su proceso de desarrollo. Incluyen los requerimientos de interoperabilidad que definen la manera en que el sistema interactúa con los otros sistemas de la organización; los requerimientos legales que deben seguirse para asegurar que el sistema opere dentro de la ley, y los requerimientos éticos. Estos últimos son impuestos al sistema para asegurar que será aceptado por el usuario y por el público en general.

DEL DOMINIO

Cuando hablamos de dominio en diseño nos referimos a aquella parte del diseño que es particular al problema que se quiere resolver. Desafortunadamente, por su misma naturaleza, es imposible ofrecer una metodología precisa debido a que cada caso es diferente. Los requerimientos de dominio (particulares) para una página web pueden ser muy diferentes de los de dominio (particulares) para un antivirus, razón por la cual la mayoría de los autores omiten ahondar en ese tema.

Por ejemplo, la mayoría de los armazones de desarrollo de aplicaciones (por ejemplo, las MFC y .NET) te ofrecen "casi todo", menos las clases de dominio, cuyos requerimientos debes tú especificar (como Dios te dé a entender) para desarrollar una aplicación de utilidad.