UNIVERSIDAD NACIONAL DEL SANTA

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE SISTEMAS E INFORMÁTICA

ACTIVIDAD DE INVESTIGACIÓN

CURSO: SISTEMAS DE INFORMACIÓN II

ESTUDIANTE:

DOCENTE:

CICLO: VI

2019
1.- ¿Qué es la programación orientada a aspectos?

La Programación Orientada a Aspectos (POA): es un paradigma de programación relativamente

reciente cuya intención es permitir una adecuada modularización de las aplicaciones y
posibilitar una mejor separación de responsabilidades (Obligación o correspondencia de hacer
algo). Gracias a la POA se pueden capturar los diferentes conceptos que componen una
aplicación en entidades bien definidas, de manera apropiada en cada uno de los casos y
eliminando las dependencias inherentes entre cada uno de los módulos. De esta forma se
consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las
implementaciones resultan más comprensibles, adaptables y reusables.

Historia

La historia de la programación orientada a aspectos toma impulso en el año 1991 con el

grupo Demeter quienes trabajaban investigando acerca de lo que podríamos denominar una
etapa temprana de POA, la programación adaptativa, la cual, basada en basada en el uso de
autómatas finitos y una teoría formal de lenguaje para expresar concisamente y procesar
eficientemente conjuntos de caminos en un grafo arquitectónico, representó un gran avance
dentro de la tecnología de software. Pero no fue hasta 1997 que Cristina Lopes comenzó a
trabajar con Gregor Kickzales y su grupo para eventualmente dejar de lado la programación
adaptativa y a partir de eso crear la Programación Orientada a Aspectos.

Conceptos de POA

Los siguientes 3 conceptos son los más importantes de la programación orientada a aspectos
general:

 Aspecto (aspect): funcionalidad transversal (se repetirá a lo largo del sistema) que será
implementada de forma separada. Es el concepto principal de este paradigma puesto
que representa la sección de código que se separó del resto del programa.
 Punto de corte (pointcut): es el que se encarga de especificar mediante expresiones
regulares (regex) en qué parte del programa se debe de insertar un aspecto.
 Consejo (advice): es el código que ejecutará el aspecto (cuerpo del algoritmo).
2.- Realiza un cuadro comparativo entre software de diseño.

ENTERPRISE STARUML RATIONAL ROSE

ARCHITECT
- Es un software de paga. - Es un software libre. - Es un software de paga.
-Tiene una interfaz - Tiene una interfaz gráfica - Entorno gráfico no muy
visualmente atractiva. aceptable. amigable para el usuario.
- No tiene soporte para COM. - No tiene soporte para COM. - Solamente ingeniería
- Genera código sin - Sobre escribe el código ya inversa para COM.
problemas. generado. - Genera código sin
- Facilidad de uso. - Facilidad de uso. problemas.
- Puede hacer ingeniería - Sólo dispone de ingeniería - Existen programas más
inversa en varios lenguajes. inversa en 3 lenguajes (C, C# fáciles de usar.
- Es un software muy popular y Java). - Puede realizar ingeniería
en el área laboral y - Es un software muy inversa en varios lenguajes
académica. conocido en el área (incluyendo antiguos como
- Tiene soporte para la etapa académica. Ada).
de Administración de un - No tiene soporte para la - Al ser un software antiguo
Proyecto (Asignación de etapa de Administración de no es muy conocido
Recursos, etc.). un proyecto. actualmente.
- También cuenta con plug- - Consta de plug-ins para - No tiene soporte para la
ins. hacer más potente al etapa de Administración de
software. un proyecto.
- Consta de plug-ins.

3.- ¿Qué es el PAPYRUS?

Eclipse Papyrus es una herramienta de ingeniería basada en modelos de código abierto de grado
industrial. Eclipse Papyrus se ha utilizado con éxito en proyectos industriales y es la plataforma
base para varias herramientas de modelado industrial.

Papyrus proporciona un entorno integrado y consumible por el usuario para editar cualquier tipo
de modelo EMF y, en particular, admite UML y lenguajes de modelado relacionados, como
SysML y MARTE. Papyrus proporciona editores de diagramas para lenguajes de modelado
basados en EMF, entre ellos UML 2 y SysML y el pegamento necesario para integrar estos
editores (basados en GMF o no) con otras herramientas MBD y MDSD. También ofrece un
soporte muy avanzado de perfiles UML que permite a los usuarios definir editores para DSL
basados en el estándar UML 2 y sus mecanismos de extensión. La característica principal de
Papyrus con respecto a este último punto es un conjunto de mecanismos de personalización muy
potentes que se pueden aprovechar para crear perspectivas Papyrus definidas por el usuario y
darle la misma apariencia que un editor DSL nativo.

Metamodelos

UML incluye un mecanismo de extensión en el propio lenguaje que permite definir lenguajes de
modelado que son derivados de UML. De forma más precisa, el paquete “Profiles” de UML 2.0
define una serie de mecanismos para extender y adaptar las metaclases de un metamodelo
cualquiera a las necesidades concretas de una plataforma (como puede ser .NET o J2EE) o de
un dominio de aplicación (tiempo real, modelado de procesos de negocio, etc.).

Existen varias razones para que un diseñador de sistemas quiera extender un metamodelo entre
las cuales podemos citar las siguientes:
  Disponer de una terminología y vocabulario propio de un dominio de aplicación o de
una plataforma de implementación concreta (por ejemplo, poder manejar dentro del
modelo del sistema terminología propia de EJB como “sesión bean”, “entity bean”,
“remote interface”, “local interface”, etc.).
 Definir una sintaxis para construcciones que no cuentan con una notación propia.
 Definir una nueva notación para símbolos ya existentes, más acorde con el dominio de
la aplicación objetivo (poder usar, por ejemplo, una figura con un ordenador en lugar
del símbolo para representar un nodo que por defecto ofrece UML para representar
ordenadores en una red).
 Añadir cierta semántica que no aparece determinada de forma precisa en el metamodelo
(por ejemplo, la incorporación de prioridades en la recepción de señales en una máquina
de estados de UML).
 Añadir cierta semántica que no existe en el metamodelo (por ejemplo relojes, tiempo
continuo, etc.).
 Añadir restricciones a las existentes en el metamodelo, restringiendo su forma de
utilización (por ejemplo, impidiendo que ciertas acciones se ejecuten en paralelo dentro
de una transición, o forzando la existencia de ciertas asociaciones entre las clases de un
modelo).
 Añadir información que puede ser útil a la hora de transformar el modelo a otros
modelos, o a código.

Estereotipos

Un estereotipo es una clase del Profile la cual se define como una metaclase existente que puede
ser extendida como parte del Profile. Permite su uso en la definición de una plataforma, o en un
dominio específico o como notación de adición a un elemento.

Un estereotipo no puede usarse por sí solo, debe ser utilizado extendiendo de una metaclase en
particular.

Un estereotipo usa la misma notación de una clase, con la palabra «stereotype» mostrándose
antes o por encima de su nombre.

Un estereotipo puede cambiar la apariencia gráfica del modelo extendido usando iconos
relacionados, representados por la clase Profile “Image”.

Ya que un estereotipo es una clase, la misma puede tener “propiedades”, las propiedades de un
estereotipo son conocidas como “Tag definitions”. Cuando el estereotipo se aplica a un
elemento del modelo, los valores de sus propiedades son conocidas como “Tagged values”.
4.- Explica el RUP, su ciclo de vida y etapas.

RUP (Rational Unified Process) es una secuencia de pasos necesarios para el desarrollo y/o
mantenimiento de gran cantidad de sistemas, en diferentes áreas de aplicación diferentes
organizaciones, diferentes medios de competencia y en proyectos de tamaños variables (desde el
más básico al más complejo). Actualmente es propiedad de International Business Machines
(IBM) y está basado en un enfoque disciplinado de asignación de tareas y responsabilidades
dentro de una organización de desarrollo con la finalidad de asegurar la obtención de un
software de alta calidad que satisfagan la necesidad de los usuarios finales dentro de un
calendario y tiempo predecible.

Elementos de RUP

 Disciplinas: son los 'contenedores' empleados para organizar todas las actividades
durante el ciclo de vida del sistema.
 Artefactos: son los elementos de entrada y salida de las actividades. Es un elemento
que el proyecto produce y utiliza para componer el producto final.
 Flujos de Trabajo: constituye la secuencia de actividades que producen resultados
visibles por medio de la integración de los roles y las actividades, artefactos y
disciplinas.
 Roles: son las personas o entes que están involucradas en cada proceso.

Ciclo de vida

El ciclo de vida RUP es una implementación del desarrollo en espiral. Fue creado ensamblando
los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e
iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan pocas pero grandes y
formales iteraciones en número variable según el proyecto. En la Figura muestra cómo varía el
esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión
del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los
riesgos críticos, y al establecimiento de una baseline (línea base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del
negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la

arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento),
análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie
de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se
procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se
realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición se pretende garantizar que se tiene un producto preparado para su
entrega a la comunidad de usuarios.

Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la
fase el esfuerzo dedicado a una disciplina varía.

Fases

 Fase de Inicio
Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores o alumnos de un proyecto en el cual tenemos que, identificar los riesgos
asociados al proyecto, proponer una visión muy general de la arquitectura de software y
producir el plan de las fases y el de iteraciones posteriores.
 Fase de Elaboración
En la fase de elaboración se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación
de los casos de uso seleccionados y el primer análisis del dominio del problema, se
diseña la solución preliminar.
 Fase de Desarrollo
El propósito de esta fase es completar la funcionalidad del sistema, para ello se deben
clarificar los requisitos pendientes, administrar los cambios de acuerdo a las
evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.
 Fase de Transición
El propósito de esta fase es asegurar que el software esté disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de aceptación,
capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el
producto cumpla con las especificaciones entregadas por las personas involucradas en el
proyecto.

Artefactos

 Inicio
 Documento Visión.
 Diagramas de caso de uso.
 Especificación de Requisitos.
 Diagrama de Requisitos.
 Elaboración
Documento de Arquitectura que trabaja con las siguientes vistas:
 Vista Lógica
 Diagrama de clases.
 Modelo E-R (Si el sistema así lo requiere).
 Vista de Implementación
 Diagrama de Secuencia.
 Diagrama de Estados.
 Diagrama de Colaboración.
 Vista Conceptual
 Modelo de Dominio.
 Vista física
 Mapa de comportamiento a nivel de hardware.
  Diseño y desarrollo de casos de uso, o flujos de casos de uso
arquitectónicos.
 Pruebas de los casos de uso desarrollados, que demuestran que la
arquitectura documentada responde adecuadamente a requerimientos
funcionales y no funcionales.
 Construcción
 Especificación de requisitos faltantes.
 Diseño y desarrollo de casos de uso y/o flujos de acuerdo con la planeación
iterativa.
 Pruebas de los casos de uso desarrollados, y pruebas de regresión según sea el
caso.
 Transición
 Pruebas finales de aceptación.
 Puesta en producción.
 Estabilización.

5.- Investigar sobre metodologías de software.

Las metodologías para el desarrollo del software imponen un proceso disciplinado sobre el
desarrollo de software con el fin de hacerlo más predecible y eficiente. Una metodología de
desarrollo de software tiene como principal objetivo aumentar la calidad del software que se
produce en todas y cada una de sus fases de desarrollo. No existe una metodología de software
universal, ya que toda metodología debe ser adaptada a las características de cada proyecto
(equipo de desarrollo, recursos, etc.) exigiéndose así que el proceso sea configurable. Las
metodologías de desarrollo se pueden dividir en dos grupos de acuerdo con sus características y
los objetivos que persiguen: ágiles y robustas.

 Metodologías Ágiles: Se caracterizan por hacer énfasis en la comunicación cara a cara,

es decir, se basan en una fuerte y constante interacción, donde clientes desarrolladores y
desarrolladores trabajan constantemente juntos, estableciéndose así una estrecha
comunicación. Estas metodologías están orientadas al resultado del producto y no a la
documentación; exige que el proceso sea adaptable, permitiendo realizar cambios de
último momento. Se puede hacer mención dentro de las metodologías ágiles a: XP (por
sus siglas en inglés Extreme Programming), Scrum y Crystal Methodologies.
 Metodologías Robustas o Tradicionales: Están guiadas por una fuerte planificación.
Centran su atención en llevar una documentación exhaustiva de todo el proceso de
desarrollo y en cumplir con un plan de proyecto, definido en la fase inicial del mismo.
Entre las metodologías robustas se encuentran: MSF (por sus siglas en inglés Microsoft
Solution Framework), MÉTRICA 3 y RUP (siglas de Rational Unified Process).

Enfoques de desarrollo de software

 Modelo en cascada
Es un proceso secuencial, fácil de desarrollo en el que los pasos de desarrollo son vistos
hacia abajo (como en una cascada de agua) a través de las fases de análisis de las
necesidades, el diseño, implantación, pruebas (validación), la integración, y
mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo
a un artículo publicado por Winston Royce W.2 en 1970, aunque Royce no utiliza el
término "cascada" de este artículo.
 Los principios básicos del modelo de cascada son los siguientes:
 El proyecto está dividido en fases secuenciales, con cierta superposición y
splashback aceptable entre fases.
 Se hace hincapié en la planificación, los horarios, fechas, presupuestos y
ejecución de todo un sistema de una sola vez.
 Un estricto control se mantiene durante la vida del proyecto a través de la
utilización de una amplia documentación escrita, así como a través de
comentarios y aprobación/signoff hechas por el usuario y la gestión del área TI
al final de la mayoría de las fases y antes de comenzar la próxima fase.
 Iterativo
El prototipo permite desarrollar modelos de aplicaciones de software que permiten ver
la funcionalidad básica de la misma, sin necesariamente incluir toda la lógica o
características del modelo terminado. El prototipo permite al cliente evaluar en forma
temprana el producto, e interactuar con los diseñadores y desarrolladores para saber si
se está cumpliendo con las expectativas y las funcionalidades acordadas. Los Prototipos
no poseen la funcionalidad total del sistema pero si condensa la idea principal del
mismo, Paso a Paso crece su funcionalidad, y maneja un alto grado de participación del
usuario.
 Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una
parte del producto software reservando el resto de aspectos para el futuro.
 Espiral
Los principios básicos son:
 La atención se centra en la evaluación y reducción del riesgo del proyecto
dividiendo el proyecto en segmentos más pequeños y proporcionar más
facilidad de cambio durante el proceso de desarrollo, así como ofrecer la
oportunidad de evaluar los riesgos y con un peso de la consideración de la
continuación del proyecto durante todo el ciclo de vida.
 Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1)
determinar objetivos, alternativas, y desencadenantes de la iteración; (2)
Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar
los resultados de la iteración, y (4) plan de la próxima iteración.
 Cada ciclo comienza con la identificación de los interesados y sus condiciones
de ganancia, y termina con la revisión y examinación.
 Rapid Application Development (RAD)
El desarrollo rápido de aplicaciones (RAD) es una metodología de desarrollo de
software, que implica el desarrollo iterativo y la construcción de prototipos. El
desarrollo rápido de aplicaciones es un término originalmente utilizado para describir
un proceso de desarrollo de software introducido por James Martin en 1991.
El objetivo es desarrollar prototipos de la aplicación de forma veloz interactuando con
el usuario formando prototipos cada vez más adecuados a la funcionalidad que se
requiere.
Para ello utiliza principalmente software de generación automática de código,
requiriendo desarrolladores especializados en el software en cuestión para evitar en
mayor medida posible los problemas de código que estos programas generan, haciendo
el mantenimiento y pulido de la aplicación o sistema más laborioso, con la ventaja de
tener el software usable en menor tiempo.
Principios básicos:
 La participacion activa de los usuarios es imprescindible.
 Iterativamente realiza la produccion de software, en lugar de enfocarse en un
prototipo.
 Produce la documentacion necesaria para facilitar el futuro desarrollo y
mantenimiento.
 El método comprende el desarrollo ITERATIVO, la construcción de prototipos
y el uso de utilidades de tipo CASE.
Prototipos Iterativos y Evolucionarios:
 Reunión JAD (Joint Application Development):
 Se reunen los usuarios finales y los desarrolladores.
 Lluvia de ideas para obtener un borrador inicial de los requisitos.
Iterar hasta acabar:
 Los desarrolladores construyen y depuran el prototipo basado en los requisitos
actuales.
 Los diseñadores revisan el prototipo.
 Los clientes prueban el prototipo, depuran los requisitos.
 Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar
los requisitos y generar solicitudes de cambios.
 Los cambios para los que no hay tiempo no se realizan. Los requisitos
secundarios se eliminan si es necesario para cumplir el calendario.
Bibliografía
Ecured. (s.f.). Ecured. Obtenido de
https://www.ecured.cu/Metodologias_de_desarrollo_de_Software

Group, S. (03 de 4 de 2017). WordPress. Obtenido de

https://sisingblog.wordpress.com/2017/04/03/metodologia-rad/

GrupoNADD. (s.f.). Rupmetodologia. Obtenido de http://rupmetodologia.blogspot.com/

Org., E. (s.f.). Eclipse.org. Obtenido de https://www.eclipse.org/papyrus/

Ruelas, U. (18 de Mayo de 2017). Codingornot. Obtenido de https://codingornot.com/que-es-

la-programacion-orientada-a-aspectos-aop