Diseño orientado a objetos es una fase de la metodología orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en términos de objetos, en vez de procedimientos, cuando planifican su código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La 'interfaz del objeto', esto es, las formas de interactuar con el objeto, también es definida en esta etapa. Un programa orientado a objetos es descrito por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis orientado a objetos.
Patrón de diseño
Es o son soluciones comunes a problemas de diseño de software orientado a objetos y que además poseen ciertas características de efectividad para resolver ese problema, reusabilidad: que puede ser reutilizado o aplicado en otros diseños o problemas, si se quiere.
Componentes
Componentes
Objetos entidad
Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleados, alumno, etc. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Objetos Interface
Representan lo objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Objetos de control
Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Representan lo objetos técnicos requeridos para vincular la aplicación con el entorno. Representan el vínculo a través del cual el sistema recibe o suministra datos e información al entorno. Típicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Objetos de control
Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente símbolo:
Clases abstractas y concretas
Una clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta. Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a través de la herencia por múltiples clases concretas. En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.
Operaciones
Una operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida). También puede contener una especificación de método, el cual especifica una implementación para la operación.
Notación: Durante la etapa de Análisis o Diseño lógico pueden utilizarse típicamente texto libre o pseudocódigo. Durante el Diseño físico dichas especificaciones son trasladadas en un lenguaje de programación específico como ser C++, Java, Visual Basic, etc.
Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implícitas. Las operaciones implícitas más importantes son Crear, Destruir, Leer, y Actualizar. Una operación implícita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales. La identificación y especificación de operaciones es una tarea clave durante el Diseño Lógico.
Atributos
Son valores de datos asociados a los objetos de una clase al cual describen. Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto.
La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase. Cada atributo identificado debe ser atómico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. dirección). Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño Físico. Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.
Restricciones
Las restricciones pueden especificarse sobre los valores que un atributo o relación pueden tomar. La implementación de las restricciones puede realizarse de diferentes formas:
reglas de validación durante los procesos de entrada de datos (user inputs)
database-level triggers
lógica de control contenida en una o más operaciones.
Una clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta. Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a través de la herencia por múltiples clases concretas. En el diagrama de estructura de objetos una clase abstracta se representa con un rectángulo punteado.
Operaciones
Una operación define un servicio ofrecido por un objeto junto con la información que debe suministrarse cuando es invocado (nombre, argumentos de entrada/salida). También puede contener una especificación de método, el cual especifica una implementación para la operación.
Notación: Durante la etapa de Análisis o Diseño lógico pueden utilizarse típicamente texto libre o pseudocódigo. Durante el Diseño físico dichas especificaciones son trasladadas en un lenguaje de programación específico como ser C++, Java, Visual Basic, etc.
Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implícitas. Las operaciones implícitas más importantes son Crear, Destruir, Leer, y Actualizar. Una operación implícita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales. La identificación y especificación de operaciones es una tarea clave durante el Diseño Lógico.
Atributos
Son valores de datos asociados a los objetos de una clase al cual describen. Están fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto.
La decisión de cuando un ítem debe considerarse como atributo o como clase varía de sistema en sistema, dependiendo de su semántica en el dominio de problema. Lo que en un sistema se modela como atributo en otro puede modelarse como una clase. Cada atributo identificado debe ser atómico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. dirección). Debe notarse que las clases no se modelan en formas normales. La decisión sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseño Físico. Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definición estándar sobre formato, longitud y dominio de valores para atributos del mismo tipo.
Restricciones
Las restricciones pueden especificarse sobre los valores que un atributo o relación pueden tomar. La implementación de las restricciones puede realizarse de diferentes formas:
reglas de validación durante los procesos de entrada de datos (user inputs)
database-level triggers
lógica de control contenida en una o más operaciones.
Relaciones Estáticas
Las relaciones estáticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo entidad-relación. Identifican así mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma clase o de otra.
Las relaciones estáticas se establecen usualmente entre objetos de tipo Entidad. Al igual que los atributos, las relaciones modelan información sobre un objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que referencian otros objetos. Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en la relación. Es posible que entre el mismo par de clases exista más de una relación. La cardinalidad identifica el número máximo y mínimo de instancias de una clase (objetos) que participan en una relación dada, en el mismo sentido que lo hacen en el modelo entidad-relación. En el diagrama de estructura de objetos utilizaremos la notación de pata-de-gallo para especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.
Las relaciones estáticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo entidad-relación. Identifican así mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma clase o de otra.
Las relaciones estáticas se establecen usualmente entre objetos de tipo Entidad. Al igual que los atributos, las relaciones modelan información sobre un objeto (cosas que un objeto debe conocer sobre sí mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que referencian otros objetos. Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en la relación. Es posible que entre el mismo par de clases exista más de una relación. La cardinalidad identifica el número máximo y mínimo de instancias de una clase (objetos) que participan en una relación dada, en el mismo sentido que lo hacen en el modelo entidad-relación. En el diagrama de estructura de objetos utilizaremos la notación de pata-de-gallo para especificar cardinalidades, aunque puede utilizarse otras como ser pares ordenados, flechas (Bachmann), etc.
Pueden observase las siguientes cardinalidades:
Mínimo 1 - Máximo 1.
Mínimo 0 - Máximo 1.
Mínimo 1 - Máximo N.
Mínimo 0 - Máximo N.
Mínimo 1 - Máximo 1.
Mínimo 0 - Máximo 1.
Mínimo 1 - Máximo N.
Mínimo 0 - Máximo N.
Comunicación por mensajes
Las asociaciones por comunicación pueden utilizarse para mostrar que objetos de una clase se comunican con objetos de otra clase o de la misma.
Una asociación por comunicación corresponde al conjunto de mensajes que son enviados por los objetos de una clase a los objetos de otra clase o de la misma.
Diseño de Interfaces para Sistemas de Información
Interfaz de usuario se refiere a los elementos y características específicas de una aplicación web, incluyendo los aspectos funcionales y visuales. El diseño de interfaz de usuario de su aplicación web puede hacer la diferencia entre una experiencia inteligente, agradable o que frustra a los usuarios. Voy a trabajar con usted para determinar los requisitos funcionales, el análisis de usuario, arquitectura de la información, el flujo de publicación, facilidad de uso, para en definitiva, crear una interfaz de usuario que proporcione una experiencia gratificante, y cumpla con sus objetivos de negocio.
Notaciones para el 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.
Notaciones para el 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 la vida resulta insatisfactoria debido a las deficiencias que presentan las métricas y los sistemas predictivos existentes en trabajo se parte de la utilización de una metodología formalizada, que permite definir dos métricas macov 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 práctica 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 de diseño
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 la vida resulta insatisfactoria debido a las deficiencias que presentan las métricas y los sistemas predictivos existentes en trabajo se parte de la utilización de una metodología formalizada, que permite definir dos métricas macov 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 práctica 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 de 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.
Generalidades
Son varios los puntos de vista relacionados con la calidad del software. Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software con medidas que pueden ayudar al desarrollador a juzgar la calidad de un diseño a nivel de componente.
Atributos de calidad
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.
Re utilizació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 Re utilizació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. Cantidad de pruebas. Consiste en el número o el grado de esfuerzo para realizar las pruebas de calidad (Unidad) del producto (componente,módulo, clase, conjunto de clases, etc.) diseñado.
Tamaño operacional de clase TOC
Está dado por el número de métodos asignados a una clase y evalúa los siguientes atributos de calidad:
Responsabilidad: Un aumento del TOC implica un aumento de la responsabilidad asignada a la clase.
Complejidad de implementación: Un aumento del TOC implica un aumento de la complejidad de implementación de la clase.
Reutilización: Un aumento del TOC implica una disminución del grado de reutilización de la clase.
Relaciones entre clases (RC)
Está dado por el número de relaciones de uso de una clase con otra y evalúa los siguientes atributos de calidad:
Generalidades
Son varios los puntos de vista relacionados con la calidad del software. Las métricas de diseño a nivel de componentes se concentran en las características internas de los componentes del software con medidas que pueden ayudar al desarrollador a juzgar la calidad de un diseño a nivel de componente.
Atributos de calidad
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.
Re utilizació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 Re utilizació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. Cantidad de pruebas. Consiste en el número o el grado de esfuerzo para realizar las pruebas de calidad (Unidad) del producto (componente,módulo, clase, conjunto de clases, etc.) diseñado.
Tamaño operacional de clase TOC
Está dado por el número de métodos asignados a una clase y evalúa los siguientes atributos de calidad:
Responsabilidad: Un aumento del TOC implica un aumento de la responsabilidad asignada a la clase.
Complejidad de implementación: Un aumento del TOC implica un aumento de la complejidad de implementación de la clase.
Reutilización: Un aumento del TOC implica una disminución del grado de reutilización de la clase.
Relaciones entre clases (RC)
Está dado por el número de relaciones de uso de una clase con otra y evalúa los siguientes atributos de calidad:
Acoplamiento: Un aumento del RC implica un aumento del Acoplamiento de la clase.
Complejidad de mantenimiento: Un aumento del RC implica un aumento de la complejidad del mantenimiento de la clase.
Reutilización: Un aumento del RC implica una disminución en el grado de reutilización de la clase.
Cantidad de pruebas: Un aumento del RC implica un aumento de la Cantidad de pruebas de unidad necesarias para probar una clase.
Matriz de inferencia de indicadores de calidad
También llamada matriz de cubrimiento, es una representación estructurada de los atributos de calidad y métricas utilizadas para evaluar la calidad del diseño propuesto. Dicha matriz permite conocer si los resultados obtenidos de las relaciones atributo/métrica es positivo o no, llevando estos resultados a una escalabilidad numérica donde, si los resultados son positivos se le asigna el valor de 1, si son negativos toma valor 0 y si no existe relación es considerada como nula y es representada con un guión simple (-). Luego se puede obtener un resultado general para cada atributo promediando todas sus relaciones no nulas.
Análisis formal del diseño
Es un resumen detallado de la investigación realizada. Es un bosquejo del propio estudio que resume los hechos, pone en relieve los problemas u oportunidades más grandes, esboza las opciones desarrolladas por los analistas y presenta sus recomendaciones. Este reporte escrito es la herramienta más importante utilizada por la gerencia para determinar si se continúa con un nuevo sistema o se modifica el existente. el análisis se realiza en términos de las fases de una investigación de sistemas:
Complejidad de mantenimiento: Un aumento del RC implica un aumento de la complejidad del mantenimiento de la clase.
Reutilización: Un aumento del RC implica una disminución en el grado de reutilización de la clase.
Cantidad de pruebas: Un aumento del RC implica un aumento de la Cantidad de pruebas de unidad necesarias para probar una clase.
Matriz de inferencia de indicadores de calidad
También llamada matriz de cubrimiento, es una representación estructurada de los atributos de calidad y métricas utilizadas para evaluar la calidad del diseño propuesto. Dicha matriz permite conocer si los resultados obtenidos de las relaciones atributo/métrica es positivo o no, llevando estos resultados a una escalabilidad numérica donde, si los resultados son positivos se le asigna el valor de 1, si son negativos toma valor 0 y si no existe relación es considerada como nula y es representada con un guión simple (-). Luego se puede obtener un resultado general para cada atributo promediando todas sus relaciones no nulas.
Análisis formal del diseño
Es un resumen detallado de la investigación realizada. Es un bosquejo del propio estudio que resume los hechos, pone en relieve los problemas u oportunidades más grandes, esboza las opciones desarrolladas por los analistas y presenta sus recomendaciones. Este reporte escrito es la herramienta más importante utilizada por la gerencia para determinar si se continúa con un nuevo sistema o se modifica el existente. el análisis se realiza en términos de las fases de una investigación de sistemas:
La fase de estudio preliminar, análisis, diseño e implantación. Además se ha discutido la auditoría posterior. Líneas generales de las actividades de investigación de sistemas. La fase de estudio preliminar (y todo el ciclo de vida de un sistema) comienza con la detección de un problema que incluye al sistema de información actual, o a la necesidad de un sistema de información donde no existía ninguno antes. La fase termina con la decisión del comité directivo de sistemas (o de un gerente de sistemas de información si es que no se tiene comité) de comenzar o no una investigación de sistemas. Si la decisión es comenzar una investigación, comienza la fase de análisis. El propósito de esta fase es determinar exactamente lo que debe realizar un sistema. El primer paso es la planeación de proyectos; después sigue una investigación del sistema o un estudio del sistema actual para conocer su estado, fuerzas y debilidades. El siguiente paso es el análisis del sistema. La información acerca del sistema actual se estudia en detalle, y se entrevista a los usuarios, se toman medidas, se desarrollan pronósticos de necesidades futuras y se toman todos los demás pasos necesarios para determinar lo que el nuevo sistema debe realizar.
Técnicas de re ingeniería e Ingeniería de reverso
Re ingenierí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, re utilización comprensión o evaluación.”
Entre las técnicas de Re ingeniería tenemos:
Re estructuració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.
Re estructuración de Código: Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de re estructuració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.
Estándares de calidad
Técnicas de re ingeniería e Ingeniería de reverso
Re ingenierí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, re utilización comprensión o evaluación.”
Entre las técnicas de Re ingeniería tenemos:
Re estructuració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.
Re estructuración de Código: Llevar a cabo esta actividad requiere analizar el código fuente empleando una herramienta de re estructuració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.
Estándares de calidad
La Internacional Organización for Standardization (ISO) es la agencia internacional especializada para la estandarización, abarcando actualmente los cuerpos nacionales de los estándares de 91 países. La ISO se compone de aproximadamente 180 comités técnicos. Cada comité técnico es responsable de una de muchas áreas de la especialización, que se extienden desde el asbesto al cinc. El propósito de la ISO es promover el desarrollo de la estandarización y de las actividades relacionadas del mundo para facilitar el intercambio internacional de mercancías y de servicios, y para desarrollar la cooperación en actividad intelectual, científica, tecnológica y económica. Los resultados del trabajo técnico de la ISO se publican como estándares internacionales.
OBJETIVO El objetivo de ISO es promover el desarrollo de la normalización y actividades conexas en el mundo, con el fin de facilitar el intercambio internacional de bienes y servicios, y desarrollar la cooperación en las esferas de actividad intelectual, científica, tecnológica y económica.
MISIÓN La misión de la ISO es promover el desarrollo de la estandarización y las actividades con ella relacionada en el mundo con la mira en facilitar el intercambio de servicios y bienes, y para promover la cooperación en la esfera de lo intelectual, científico, tecnológico y económico.
VISIÓN: En el contexto actual y con visión al futuro, como alcanzar la Misión.
Herramienta CASE
OBJETIVO El objetivo de ISO es promover el desarrollo de la normalización y actividades conexas en el mundo, con el fin de facilitar el intercambio internacional de bienes y servicios, y desarrollar la cooperación en las esferas de actividad intelectual, científica, tecnológica y económica.
MISIÓN La misión de la ISO es promover el desarrollo de la estandarización y las actividades con ella relacionada en el mundo con la mira en facilitar el intercambio de servicios y bienes, y para promover la cooperación en la esfera de lo intelectual, científico, tecnológico y económico.
VISIÓN: En el contexto actual y con visión al futuro, como alcanzar la Misión.
Herramienta 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).
Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
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.
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.
