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.





viernes, 11 de noviembre de 2011

PROCESO DE DESARROLLO DE SOFTWARE




PROCESO DE DESARROLLO DE SOFTWARE


FUNDAMENTOS DEL ENFOQUE ORIENTADO A OBJETOS

El paradigma OO se basa en el concepto de objeto. Un objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común.

La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.

CARACTERÍSTICAS

En el enfoque OO las propiedades del objeto son claves. Los principios del modelo OO son: abstracción, encapsulación, modularidad y jerarquía, fundamentalmente, y en menor grado tipificación (typing), concurrencia, persistencia. [Booch 1986] dice que si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO.

  • Abstracción. Es una descripción simplificada o especificación de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
  • Encapsulación. En el proceso de ocultar todos los detalles de un objetoque no contribuyen a sus características esenciales.
  • Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.
  • Jerarquía o herencia. Es el orden de las abstracciones organizado por niveles.
  • Tipificación. Es la definición precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.
  • Concurrencia . Es la propiedad que distingue un objeto que está activo de uno que no lo está.
  • Persistencia. Es la propiedad de un objeto a través de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o el espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado).
APLICABILIDAD

Claridad

Al ligar de forma evidente la estructura de la información con los procedimientos que la manipulan, los programas ganan en claridad a la hora de desarrollarlos y mantenerlos. Esto supone una ventaja frente a los lenguajes procedurales , aunque éstos podrían suplir esta deficiencia mediante una correcta elección de los nombres de las variables y funciones, lo que se denomina una <>.

Complejidad

Cuando la complejidad de un problema es abarcable por una sola persona, resolverlo con una herramienta u otra no aporta grandes ventajas. Pero cuando este desarrollo la tiene que realizar un equipo grande, debe existir una forma para aislar partes de problema.

  • Tamaño

Las aplicaciones orientadas a objetos son ideales para la realización de programas de gran tamaño. Las facilidades de encapsulación y asociación de las funciones a los datos que manipulan, simplifican el proceso de desarrollo. De hecho las bases de datos orientadas a objetos suponen un gran adelanto, ya que aúnan la flexibilidad en la manipulación de los OOP con la capacidad de consulta de un DBMS (Data Base Management System)

Relación entre Datos

Por el mismo motivo se verán beneficiados aquellos programas que impliquen una relación compleja entre los datos. Este tipo de complejidad permite la utilización de todas las ventajas de los lenguajes de programación orientados a objetos. Propiedades como la herencia ( donde los objetos pueden heredar estructura y operaciones de objetos predecesores), la encapsulación, etc. Muestran en este tipo de programas todas sus ventajas.

Rapidez

En este aspecto, los lenguajes orientados a objetos muestran una clara desventaja frente a otros lenguajes que se acercan más a las especificaciones de la máquina. Si la rapidez es crítica, puede elegir un lenguaje de programación como C++, que aporta toda la funcionalidad de los lenguajes orientados a objetos con la rapidez y la compatibilidad de C.

Gestión de recursos

Las aplicaciones orientadas a objetos demandan normalmente más recursos del sistema que las aplicaciones procedurales. La creación dinámica de objetos, que ocupa un lugar en la memoria del ordenador, puede acarrear graves problemas. Una de las soluciones, que incluye alguno delos lenguajes OOP, es liberar a menudo el espacio que los objetos dejan de utilizar. Este procedimiento de optimización como garbage collection (recolección de basura, implementado en java), minimiza los efecto de la creación dinámica de objetos.

Interface de usuario.

El interface de usuario es uno de los aspectos más importantes en la programación actual. La aparición de sistemas de explotación que soportan un interface gráfico de usuario como Windows, X-Windows o Presentation Manager hace que la mayoría de los usuarios prefieran que sus programas corran bajo este tipo de interface. Este es uno de los puntos fuertes para la elección de un lenguaje OOP.
ESTANDARES EN EL PROCESO DE DESARROLLO DE SOFTWARE

Un proceso para el desarrollo de software, también denominado ciclo de vida del desarrollo de software es una estructura aplicada al desarrollo de un producto de software. Hay varios modelos a seguir para el establecimiento de un proceso para el desarrollo de software, cada uno de los cuales describe una enfoque diferente para diferentes actividades que tienen lugar durante el proceso. Algunos autores consideran un modelo de ciclo de vida un término más general que un determinado proceso para el desarrollo de software. Por ejemplo, hay varios procesos de desarrollo de software específicos que se ajustan a un modelo de ciclo de vida de espiral.
DOCUMENTACIÓN Y ARTEFACTOS

Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar.

Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema:
Ejemplo de algunos de los diagramas que utiliza UML. Diagramas de Implementación Se derivan de los diagramas de proceso y módulos de la metodología de Booch, aunque presentan algunas modificaciones. Los diagramas de implementación muestran los aspectos físicos del sistema. Incluyen la estructura del código fuente y la implementación, en tiempo de implementación. Existen dos tipos: Diagramas de componentes Diagrama de plataformas despliegue

PROCESO UNIFICADO DE DESARROLLO

Es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos específicos. De la misma forma, el Proceso Unificado de Rational, también es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genérico que incluye aquellos elementos que son comunes a la mayoría de los refinamientos existentes. También permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denominó, en su versión española, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos también por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no están afiliados a Rational utilizan el término Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.

INTRODUCCIÓN AL MODELADO

El Modelo de Objetos del Documento (DOM) es una interfaz de programación de aplicaciones (API) para documentos validos HTML y bien construidos XML. Define la estructura lógica de los documentos y el modo en que se accede y manipula. En la especificación DOM, el término "documento" es utilizado en un sentido amplio - the term "document" is used in the broad sense - cada vez más XML es utilizado como un medio de representar muchas clases diferentes de información que puede ser almacenada en sistemas diversos, y mucha de esta información se vería, en términos tradicionales, más como datos que como documentos. Sin embargo, XML presenta estos datos como documentos, y se puede utilizar DOM para manejar estos datos.

Con el Modelo de Objetos del Documento, los programadores pueden construir documentos, navegar por su estructura, y añadir, modificar, o eliminiar elementos y contenido. Se puede acceder a cualquier cosa que se encuentre en un documento HTML o XML, modificando, borrando o añadiendo utilizando el Modelo de Objetos del Documento, con algunas excepciones - en particular, aún no se han especificado aplicaciones DOM para los subconjuntos interneto y externos de XML.

CARACTERISTICAS DE LOS LENGUAJES DE MODELADO

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.

El lenguaje está dotado de múltiples herramientas para lograr la especificación determinante del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:


DIAGRAMAS, SIMBOLOS Y NOTACIÓN

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.













<!--[if gte mso 9]> Normal 0 21 false false false ES X-NONE X-NONE MicrosoftInternetExplorer4