Ingeniería de Software Asistida por

Computadora
Herramientas CASE

Curso: Tecnología de desarrollo de aplicaciones

Docente: Magali Gianina Gonzales Paco

email: magigianis@gmail.com
 Definición
•Las herramientas CASE (Computer Aided
Software Engineering, Ingeniería de Software
Asistida por Computadora) son diversas
aplicaciones informáticas o programas
informáticos destinadas a aumentar la
productividad en el desarrollo de software
reduciendo el costo de las mismas en términos
de tiempo y de dinero..
 Objetivo
•Mejorar la productividad del software.
•Aumentar la calidad del software.
•Reducir el tiempo y costo de desarrollo y
mantenimiento de los sistemas informáticos.
•Mejorar la planificación de un proyecto.
•Aumentar la biblioteca de conocimiento
informático de una empresa ayudando a la
búsqueda de soluciones para los requisitos.
 Objetivo
• Automatizar el desarrollo del software, la
documentación, la generación de código, las
pruebas de errores y la gestión del proyecto.
• Ayuda a la reutilización del software, portabilidad
y estandarización de la documentación.
• Gestión global en todas las fases de desarrollo de
software con una misma herramienta.
• Facilitar el uso de las distintas metodologías
propias de la ingeniería del software.
 Características deseables
• Soporte gráfico para varias técnicas (DFD, DER,
modelos OO, etc.)
• Control de errores, unicidad de identificadores,
reglas, metodología, etc.
• Control de documentos y versiones.
• Métricas del software.
• Simulación y prototipado.
• Generación de código.
• Verificación entre diferentes modelos
 CLASIFICACION
•Aunque es difícil y existen muchas formas de
clasificarlas, las herramientas CASE se
pueden clasificar teniendo en cuenta los
siguientes parámetros:
• Las plataformas que soportan.
• Las fases del ciclo de vida del desarrollo de
sistemas que cubren.
• La arquitectura de las aplicaciones que
producen.
• Su funcionalidad.
 CLASIFICACION:
•Según fases del ciclo de vida del desarrollo
La siguiente clasificación es la más habitual basada en las
fases del ciclo de desarrollo que cubren:
• Upper CASE (U-CASE), herramientas que ayudan en las
fases de planificación, análisis de requisitos y estrategia del
desarrollo, usando, entre otros diagramas UML.
• Middle CASE (M-CASE), herramientas para automatizar
tareas en el análisis y diseño de la aplicación.
• Lower CASE (L-CASE), herramientas que semi-automatizan
la generación de código, crean programas de detección de
errores, soportan la depuración de programas y pruebas.
Además automatizan la documentación completa de la
aplicación. Aquí pueden incluirse las herramientas
de desarrollo rápido de aplicaciones.
 CLASIFICACION:
• Otras clasificaciones
• Existen otros nombres que se le dan a este tipo de herramientas, y que
no es una clasificación excluyente entre sí, ni con las fases del ciclo de
vida del desarrollo:
• Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo software, desde el análisis hasta la implementación.
• MetaCASE, herramientas que permiten la definición de nuestra propia
técnica de modelado, los elementos permitidos del metamodelo
generado se guardan en un repositorio y pueden ser usados por otros
analistas, es decir, es como si definiéramos nuestro propio UML, con
nuestros elementos, restricciones y relaciones posibles.
• CAST (Computer-Aided Software Testing), herramientas de soporte a la
prueba de software.
• IPSE (Integrated Programming Support Environment), herramientas que
soportan todo el ciclo de vida, incluyen componentes para la gestión de
proyectos y gestión de la configuración activa.
 CLASIFICACION:
Según funcionalidad
Por funcionalidad se pueden diferenciar algunas como:

Herramientas de generación semiautomática de código.

Editores UML.
Herramientas de refactorización de código.
Herramientas de mantenimiento como los sistemas de control de
versiones·
Componentes de un CASE
INTERFAZ DE USUARIO

Repositorio Metamodelo

HERRAMIENTAS
GENERADOR DE DE CARGA Y
INFORMES DESCARGA DE
DATOS

FACILIDADES DE INTEGRACION
Taxonomía
• Herramientas de gestión
• Herramientas técnicas
• Herramientas de soporte
• Herramientas de apoyo a las primeras fases
• Análisis, diseño
• Herramientas de apoyo a las ultimas fases
• Implementación (generación de código).
• Pruebas (caja blanca y caja negra).
• Mantenimiento.
 Categorías CASE
PLANIFICACIÓN DIMENSIONAMIENTO
HERRAMIENTAS DE
GESTIÓN SEGUIMIENTO

ANÁLISIS DISEÑO IMPLEMENTACIÓN PRUEBA MANTENIMIENTO

HERRAMIENTAS CASE CASE GENERADORES DE HERR. DE HERRAMIENT. DE

TÉCNICAS FRONTAL DORSAL CÓDIGO PRUEBA MANTENIMIENTO

CASE INTEGRADO y LENGUAJES DE 4ª GENERACIÓN

SISTEMA DE REPOSITORIO / DICCIONARIO

HERRAMIENTAS DE
SOPORTE CONTROL DE CONFIGURACIÓN SERVICIOS DE SEGURIDAD
 Ejemplos
• Prototipado
• Diseñadores de pantallas
• Generadores de menús
• Generadores de informes
• Lenguajes de especificación ejecutables

• Diseño
• DESIGNER/2000 de ORACLE
• EASY CASE
• Rational ROSE
• OBJECT MAKER
• OMTool de GTE.
• Visual Paradigma
• SYSTEM Architect
 Criterios de Selección
• Tipo de computador
• Lenguaje al que va orientada.
• Metodología y técnicas soportadas.
• Posibilidades de integración con otras plataformas
(presente y futuro).
• Criterios habituales en la selección de software
• Formación
• Precio
• Asistencia técnica
• Mantenimiento
 Wireframes y herramientas
de prototipado
• Son herramientas que nos permiten realizar el diseño y
representaciones esquemáticas de los componentes gráficos de
nuestras aplicaciones.
• Un ejemplo es la herramienta “mockingbird”, herramienta online que
permite realizar wireframes de una forma sencilla y permite
compartir los resultados de los trabajos realizados en ella con
diferentes personas.
• Otro ejemplo es la herramienta “gliffy”, muy potente, que permite
crear gran cantidad de diagramas, pero también permite crear
wireframes de aplicaciones Web, ya sean estáticos o interactivos para
simular la navegación entre páginas. Permite el trabajo colaborativo y
exportar los diseños en diferentes formatos para su presentación o
almacenamiento.
 Rational Rose
Rational Rose es una herramienta de diseño orientada a objetos, que da
soporte al modelado visual, es decir, que permite representar gráficamente el
sistema, permitiendo hacer énfasis en los detalles más importantes,
centrándose en los casos de uso y enfocándose hacia un software de mayor
calidad, empleando un lenguaje estándar común que facilita la comunicación.

Proporciona mecanismos para realizar la Ingeniería Inversa, es decir, que a

partir del código se pueda obtener información sobre su diseño;
adicionalmente permite generar código en diferentes lenguajes a partir de un
diseño en UML, brinda la posibilidad de que varias personas trabajen a la vez,
permitiendo que cada desarrollador opere en un espacio de trabajo privado
que contiene el modelo completo y permite que tenga un control exclusivo
sobre la propagación de los cambios en ese espacio de trabajo. El desarrollo es
un proceso iterativo, que comienza con una aproximación del análisis, diseño e
implementación para identificar los riesgos y probar el sistema, cuando la
implementación pasa todas las pruebas que se determinan, se añaden los
elementos modificados al modelo y una vez modificado el modelo se realiza la
siguiente iteración. Rational, además, soporta los diagramas de UML, excepto
los Diagramas de Implementación.
 UML
• El lenguaje unificado de modelado (UML, por sus siglas en inglés, Unified
Modeling Language) es el lenguaje de modelado de sistemas
de software más conocido y utilizado en la actualidad; está respaldado por
el Object Management Group (OMG).
• Es un lenguaje gráfico para visualizar, especificar, construir y documentar un
sistema. UML ofrece un estándar para describir un "plano" del sistema
(modelo), incluyendo aspectos conceptuales tales como procesos, funciones
del sistema, y aspectos concretos como expresiones de lenguajes de
programación, esquemas de bases de datos y compuestos reciclados.
• Es importante remarcar que UML es un "lenguaje de modelado" para
especificar o para describir métodos o procesos. Se utiliza para definir un
sistema, 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 el desarrollo de software gran variedad de formas para
dar soporte a una metodología de desarrollo de software (tal como
el Proceso Unificado Racional, Rational Unified Process o RUP), pero no
especifica en sí mismo qué metodología o proceso usar.
EL PROCESO UNIFICADO DE RATIONAL
( RUP )

Ing. Magali Gonzales Paco

Email: magigianis@gmail.com
El Triángulo de Desarrollo de Software

Proceso

Herramienta
Notación Visual
 UNIFIED SOFTWARE
DEVELOPMENT PROCESS
•Proceso Unificado
•Proceso de desarrollo de Software

• Ivar Jacobson
• Grady Booch
• James Rumbaugh
 Proceso Software
“Un proceso bien definido es necesario para
desarrollar sistemas software de manera repetible y
predecible”

“Permite un negocio sostenible y que puede mejorar

en cada nuevo proyecto, incrementando la eficiencia
y productividad de la organización”

G. Booch
¿Qué es un Proceso de Desarrollo de SW?
 Define Quién debe hacer Qué, Cuándo y Cómo debe
hacerlo

Requisitos nuevos Sistema nuevo

o modificados o modificado
Proceso de Desarrollo
de Software

 No existe un proceso de software universal. Las

características de cada proyecto (equipo de
desarrollo, recursos, etc.) exigen que el proceso sea
configurable
Rational Unified Process (RUP)

Rational Unified Process • Pruebas funcionales

1998 • Pruebas de desempeño
• Gestión de requisitos
• Gestión de cambios y
configuración
• Ingeniería de Negocio
Rational Objectory Process • Ingeniería de datos
1996-1997
• Diseño de interfaces

Objectory Process UML

1987-1995

Enfoque Ericsson
Proceso Unificado de Rational (RUP)
 LA VIDA DEL PROCESO
UNIFICADO
El Proceso Unificado se repite a lo largo de una
serie de ciclos que constituyen la vida de un
Sistema.

Cada ciclo concluye con un versión del Producto

para los clientes.

Cada ciclo consta de cuatro fases:

Inicio,
Elaboración,
Construcción y
Transición.
Fases e Hitos

Inception Elaboration Construction Transition

Objetivos Arquitectura Capacidad Release

(Vision) Operacional del Producto
Inicial

tiempo
 FASES DENTRO DE UN CICLO
• Durante la Fase de Inicio, se desarrolla una
descripción del producto final y se presenta el
análisis de negocio para el producto.
• Durante la Fase de Elaboracion, se especifica
en mayor detalle los casos de uso, se define la
Arquitectura .
• Durante la Fase de Construccion, el software
es desarrollado a partir de una línea base de la
arquitectura ejecutable, hasta el punto en el que
esta listo para ser transmitido a la comunidad de
usuarios.
 FASES DENTRO DE UN CICLO

• En la Fase de Transicion el software es puesta

en manos de la comunidad de usuarios.
La arquitectura : Se expresa en forma de vistas
de todos los modelos del sistema, los cuales
representan el sistema entero. Al finalizar esta
fase el jefe de proyecto esta en disposición de
planificar actividades y estimar recursos.
Elementos en RUP
 Workflows (Disciplinas)
Workflows Primarios
• Business Modeling (Modado del Negocio)
• Requirements (Requisitos)
• Analysis & Design (Análisis y Diseño)
• Implementation (Implementación)
• Test (Pruebas)
• Deployment (Despliegue)
Workflows de Apoyo
• Environment (Entorno)
• Project Management (Gestión del Proyecto)
• Configuration & Change Management (Gestión de
Configuración y Cambios)
 LA VIDA DEL PROCESO
UNIFICADO
Tiempo

Inicio Elaboración Construcción Transición

Iteración #1
Iteración #2

Versiones
Fases, Iteraciones y Flujos de Trabajo
Alcances y Versión Versión
Objetivos Arquitectura Beta Final

Fases: Inicio Elaboración Construcción Transición

Iteración Iteración Iteración Iteración

Iteraciones: 1 2 ... n

Requerimientos

Análisis y Diseño Entregas

Codificación Internas
Flujos de Trabajo:
Prueba
Admin. Proyecto
Gestión Configur.
y Cambio
... Elementos en RUP
Workflow, Workflow Detail , Roles, Actividades y Artefactos
Ejemplo
Workflow: Requirements Workflow Detail:Analyse the Problem

Roles Artefactos
Actividades
Roles
Analyst
 Business-Process Analyst
 Business Designer

Business-Model Reviewer
 Requirements Reviewer
 System Analyst
 Use-Case Specifier
 User-Interface Designer
Developer
 Architect
 Architecture Reviewer
 Capsule Designer
 Code Reviewer
 Database Designer
 Design Reviewer
 Designer
 Implementer
 Integrator
... Elementos en RUP
Testing professional
 Test Designer
 Tester
Manager
 Change Control Manager
 Configuration Manager
 Deployment Manager
 Process Engineer
 Project Manager
 Project Reviewer
Other
 Course Developer
 Graphic Artist
 Stakeholder
 System Administrator
 Technical Writer
 Tool Specialist
Roles, Actividades, Artefactos
Ejemplo: Rol System Analyst
Artefactos

Resultado parcial o final que es producido y
usado durante el proyecto. Son las entradas y
salidas de las actividades

Un artefacto puede ser un documento, un modelo
o un elemento de modelo

Conjuntos de Artefactos

 Business Modeling Set

 Deployment Set
 Requirements Set  Project Management Set
 Analysis & Design Set  Configuration & Change
 Implementation Set Management Set
 Environment Set
 Test Set
Artefactos, Roles, Actividades
Ejemplo:Business Modeling Artifact Set
 Caracteristicas esenciales del Rup

• Proceso dirigido por casos de uso

• Centrado en la arquitectura

• Proceso iterativo e incremental.

 EL PROCESO UNIFICADO DIRIGIDO
POR CASOS DE USO
• Los casos de uso se utilizan como artefacto
principal para definir el comportamiento
deseado para el sistema (Que debe hacer el
sistema ), y para comunicar este
comportamiento entre las personas involucradas
en el sistema.
• También guían su diseño, implementación y
prueba
• Se desarrollan a la vez que la Arquitectura.
Proceso dirigido por los Casos de Uso
Capturar, definir y
validar los casos de
Requisitos uso

Análisis & Diseño Casos de Uso

Realizar los
integran el
casos de uso
Implementación trabajo

Pruebas Verificar que se

satisfacen los
casos de uso
 EL PROCESO UNIFICADO DIRIGIDO POR
CASOS DE USO

• Es decir los casos de uso guían la arquitectura del Sistema y la

arquitectura del Sistema influye en la selección de los casos de
uso. Por lo tanto ambos maduran según avanza el ciclo de vida.
 EL PROCESO UNIFICADO
CENTRADO EN LA ARQUITECTURA

• En el contexto del ciclo de vida del Software,

significa que la arquitectura de un sistema se usa
como un artefacto principal para la
conceptualización, construcción, gestión y
evolución del sistema en desarrollo
... Proceso dirigido por los Casos de Uso

«trace» «trace»

Caso de Uso Realización de Análisis Realización de Diseño

«trace»
«trace»
Pruebas
Unitarias
Pruebas Funcionales X
Caso de Prueba
... Proceso dirigido por los Casos de Uso
 EL PROCESO UNIFICADO ES
ITERATIVO E INCREMENTAL
• Es útil dividir el trabajo en partes más pequeñas o
miniproyectos.
• Cada miniproyecto es una iteración que resulta en un
incremento.
• Las iteraciones hacen referencia a pasos del flujo de
trabajo, y los incrementos al crecimiento del trabajo.
• Para una efectividad máxima, las iteraciones deben
estar controladas, es decir deben seleccionarse y
ejecutarse e forma planificada.
 EL PROCESO UNIFICADO ES
ITERATIVO E INCREMENTAL
Iterativo : Proceso que implica la gestión de una
serie de versiones ejecutables.
Integracion Incremental : Proceso que implica
la integracion continua de la Arquitectura del
Sistema para producior versiones de forma
que cada nueva version,incluya mejoras
incrementales sobre las anteriores.
 En el ciclo de vida iterativo a cada iteración
se reproduce el ciclo de vida en cascada a
menor escala
 ...EL PROCESO UNIFICADO ES
ITERATIVO E INCREMENTAL
Análisis
Diseño
Codific.
Pruebas e
n veces Integración
 Los objetivos de una nueva iteración se
establecen en función de la evaluación de las
iteraciones precedentes
 Las actividades se encadenan en una mini-cascada
con un alcance limitado por los objetivos de la
iteración
 ....EL PROCESO UNIFICADO ES ITERATIVO E
INCREMENTAL
Cada iteración comprende:
 Planificar la iteración (estudio de riesgos)
 Análisis de los Casos de Uso y escenarios
 Diseño de opciones arquitectónicas
 Codificación y pruebas. La integración del nuevo código con el
existente de iteraciones anteriores se hace gradualmente durante
la construcción
 Evaluación de la entrega ejecutable (evaluación
del prototipo en función de las pruebas y de los criterios definidos)
 Preparación de la entrega (documentación e instalación del
prototipo)
Proceso Iterativo e Incremental

Enfoque
Secuencial

Enfoque
Iterativo e
Incremental
... Proceso Iterativo e Incremental
Grado de Finalización de Artefactos
 EL PROCESO UNIFICADO CENTRADO EN
LA ARQUITECTURA

• De manera resumida podemos decir que el

arquitecto :
• Crear un esquema en borrador de la arquitectura,
comenzando por la parte de la arquitectura que no es
especifica de los casos de uso
• A continuación, el arquitecto trabaja con un
subconjunto de los casos de uso especificados
• A medida que los casos de usos e especifican y
maduran, se descubre más del a arquitectura.
EL PROCESO UNIFICADO CENTRADO EN LA
ARQUITECTURA
 Arquitectura de un sistema es la organización o estructura
de sus partes más relevantes
 Un arquitectura ejecutable es una implementación parcial
del sistema, construida para demostrar algunas funciones y
propiedades

 RUP establece refinamientos sucesivos de una arquitectura

ejecutable, construida como un prototipo evolutivo

Inception Elaboration Construction Transition

Architecture
Fases, Release, Linea Base,
Generación
ciclo de desarrollo ciclo de evolución

release base line generación

(producto al final de (release asociada (release final de
una iteración) a un hito) un ciclo de desarrollo)
 Flujos de Trabajo Fundamentales

• Modelo del Negocio

• Modelo de Requisitos
• Modelo del Análisis
• Modelo del Diseño
• Modelo de Implementación
• Pruebas e Implantación
• Configuración y manejo de Cambios
• Dirección de Proyectos
MODELO DE NEGOCIOS
MODELO DE NEGOCIOS
MODELO DE NEGOCIOS
MODELO DE NEGOCIOS
 MODELO DE NEGOCIOS
1. Evaluar la organización objetivo.
 EJEMPLO C.U. NEGOCIO
Caso empresa GALLO S.A.
Gallo S.A. es una empresa dedicada a la venta de artículos electrodomésticos. Esta empresa
cuenta con diferentes puntos de venta. Cada punto de venta cuenta con cajeros, vendedores
y su propio almacén.
Un día X en Gallo S.A. comienza cuando un cliente solicita al vendedor un producto que se
encuentra en vitrina. El vendedor verifica el stock de ese producto y si hay stock, le muestra
e informa de las características de ese producto. Si el cliente está de acuerdo con el
producto ofrecido, el vendedor le generará un ticket de pedido indicándole el código del
producto y el precio.
Puede ocurrir que el producto que se encuentra en vitrina no exista en la tienda por lo que
el vendedor se comunicará con su proveedor para consultar si el producto existe; en caso
que tampoco exista, el vendedor, para no perder a su cliente, le informará que existen
productos sustitutos, con las mismas características del producto que desea y al mismo
precio. El cliente puede ser que acepte o no el producto.
El cliente se dirige a caja y el cajero le solicita el ticket de pedido para que le genere el
comprobante de pago. El cajero le entrega el comprobante de pago al cliente y éste se dirige
con el comprobante de pago al vendedor para que le haga entrega del producto.
Se solicita elaborar lo siguiente:
1. El Modelo de Casos de Uso del Negocio.
2. El Modelo de Análisis del Negocio.
Figura 1. Diagrama de Casos de Uso del Negocio
Figura 2. Diagrama de Actividades del proceso de Venta de
electrodomésticos