Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SEGUNDA UNIDAD
21 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Lección 3
Definición
• Análisis del
Sistema Desarrollo
• Requerimientos
• Planificación
• Diseño
• Codificación Evolución
• Prueba
• Corrección
• Adaptación
• Mejora
22 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Análisis del sistema. Define el papel de cada elemento del sistema de información,
asignando finalmente al software el papel que va a desempeñar.
Requerimientos del software. El ámbito establecido para el software proporciona la
dirección a seguir, pero antes de comenzar a trabajar es necesario disponer de una
información mas detallada del ámbito de la funcionalidad del software.
Planificación del proyecto de software. Una vez establecido el ámbito del software, se
analizan los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y
se planifica el trabajo.
23 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
En este modelo, los requerimientos deben estar claramente identificados desde el inicio.
Sin embargo, la realidad señala que raramente el cliente expone todos los requerimientos
desde el inicio. En consecuencia, pueden surgir cambios durante el desarrollo lo que
afectará la planificación establecida.
Cuando se trata de proyectos grandes, el cliente debe tener paciencia porque no verá una
versión operativa del sistema sino hasta que el proyecto esté muy avanzado. Además,
24 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
esto hace que no exista una validación por parte del cliente hasta muy tarde. Si en estas
etapas finales se detectase un error grave las consecuencias son desastrosas.
Aunque este modelo puede tener sus debilidades, siempre es mejor que un enfoque
hecho al azar y puede resultar bueno cuando se trate de un proyecto donde todos los
requerimientos están claramente definidos desde el comienzo.
En este modelo, cuando el cliente observa el prototipo operativo, cree que es la versión
final del sistema, sin entender que se trata de solo un prototipo y que el producto no está
terminado.
Por la presión de hacer que el prototipo funcione rápidamente, el desarrollador puede
elegir, inadecuadamente, el sistema operativo o el lenguaje de programación; incluso,
puede usar un algoritmo incorrecto. Después de algún tiempo, puede familiarizarse con
estas elecciones y olvidarse las razones por las cuales son inadecuadas, dejándolas luego
como una parte integral del sistema.
Aunque pueden surgir estos problemas, éste es un modelo útil a la hora de construir un
sistema donde no se tiene claros los requisitos inicialmente. La clave está en establecer
claramente, al principio, las reglas de juego con el cliente y llegado el momento, no ceder
a la presión de éste para conservarlo como producto final.
25 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
26 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Este modelo es particularmente útil cuando no se está seguro de poder cumplir con los
plazos de tiempo debido a falta de personal de desarrollo, o cuando se tenga una fecha
27 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
imposible de cambiar, ya que en todos los casos, el cliente se queda con una versión
operativa del producto.
A diferencia del modelo lineal secuencial que termina cuando se entrega el software, el
modelo en espiral puede ser adaptado para ser aplicado a un proyecto que se encuentre
en cualquier punto del ciclo de desarrollo.
Cada cubo en la figura 3.6 representa un punto de entrada para un tipo diferente de
proyecto. Podemos arrancar desde el cubo de más adentro para el caso de un proyecto
de desarrollo de conceptos hasta que el desarrollo del modelo conceptual haya finalizado.
Si el concepto va a ser desarrollado en un producto real, el proceso avanza hasta el
próximo cubo, y así sucesivamente para los distintos tipos de proyectos. De esta forma, el
proceso puede permanecer parado por un tiempo, pero siempre que un cambio ocurre, el
proceso reinicia desde el punto de entrada apropiado (por ejemplo, proyecto de mejora
del producto).
28 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
3.3 Metodologías
Asociado al concepto de proceso de desarrollo de sistemas de información, software, o
aplicaciones informáticas, está el concepto de Metodología de Desarrollo.
Una Metodología es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software (Pressman, 2005).
Una metodología representa el camino a seguir para desarrollar software o aplicaciones
informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en
etapas, actividades y tareas.
Una tarea es una actividad elemental siguiendo algún procedimiento. El procedimiento es
la definición de la forma de ejecutar la tarea. La técnica es la herramienta utilizada para
aplicar un procedimiento. Se pueden utilizar una o varias. Una herramienta es el soporte
software que apoya la aplicación de una técnica. Un producto es el resultado de cada
fase, etapa o actividad de una metodología.
Se han establecido diversas metodologías para el desarrollo de sistemas de información,
algunas de las mas citadas son: RUP, MÉTRICA V3, Merisse, SSADM V4, MDSI.
3.3.1 RUP
Rational Unified Process, de la compañía IBM, es una plataforma de proceso de desarrollo
de software configurable que entrega mejores prácticas comprobadas y una arquitectura
configurable. Permite seleccionar y desplegar solamente los componentes de proceso
que usted necesita para cada etapa de su proyecto.
El RUP es un proceso de desarrollo de software y junto con UML (Lenguaje Unificado de
Modelado), constituye la metodología estándar más utilizada para el análisis,
implementación y documentación de sistemas orientados a objetos.
Link: http://www-01.ibm.com/software/pe/rational/rup.shtml
3.3.2 MÉTRICA V3
MÉTRICA, versión 3, Metodología de Planificación, Desarrollo y Mantenimiento de
Sistemas de Información, del Consejo Superior de Administración Electrónica del
Ministerio de la Presidencia del Gobierno de España, ofrece a las Organizaciones un
instrumento útil para la sistematización de las actividades del proceso de desarrollo
dentro del marco que permite alcanzar los siguientes objetivos:
• Proporcionar o definir Sistemas de Información que ayuden a conseguir los fines de la
Organización mediante la definición de un marco estratégico para el desarrollo de los
mismos.
• Dotar a la Organización de productos software que satisfagan las necesidades de los
usuarios dando una mayor importancia al análisis de requisitos.
• Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la
Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a
los cambios y teniendo en cuenta la reutilización en la medida de lo posible.
• Facilitar la comunicación y entendimiento entre los distintos participantes en la
producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta
su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos.
29 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
3.3.3 Merisse
Merise es un método integrado de análisis, concepción y gestión de proyectos,
desarrollado en Francia, que provee un marco metodológico y un lenguaje común
riguroso para los desarrollos informáticos.
Es una metodología de modelado de propósito general en el ámbito del desarrollo de
sistemas de información, ingeniería de software y gestión de proyectos. Fue introducido
en la década de 1980, desarrollado y perfeccionado hasta el punto en que las
organizaciones no gubernamentales francesas, comerciales e industriales más grandes la
han adoptado como metodología estándar.
Merise separa el tratamiento de datos y de procesos, donde la vista de datos se modela
en tres fases: conceptual, lógico y físico. Del mismo modo, la vista de proceso pasa a
través de tres etapas: conceptual, organizacional y operacional. Estas etapas en el
modelado de proceso son paralelas con las etapas del ciclo de vida: planificación
estratégica, el estudio preliminar, un estudio detallado, desarrollo, implementación y
mantenimiento.
Link: http://merise.developpez.com/
3.3.4 SSADM V4
El Método de análisis y diseño estructurado de sistemas (SSADM Structured Systems
Analysis and Design Method (SSADM) es un enfoque de sistemas para el análisis de
sistemas de información; fue producido por Central Computer and Telecommunications
Agency (nahora Office of Government Commerce), una oficina gubernamental de Reino
Unido relacionada con el uso de tecnología en el gobierno, a partir de 1980.
Las tres técnicas más importantes que se utilizan en SSADM son: Modelado lógico de
Datos, Modelado de flujo de datos y Modelado de comportamiento de entidades.
Desde 1981 SSADM se ha perfeccionado y la versión 4 fue lanzado en 1990. SSADM es un
estándar abierto, es decir, que esta disponible gratuitamente para su en la industria y
muchas empresas ofrecen servicios de apoyo, formación y herramientas CASE para ello.
3.3.5 MDSI
La metodología MDSI Versión 2.0, es una herramienta desarrollada en base a la
metodología de Métrica 3 del Ministerio de Administración Pública de España (MAP) y
RUP (Rational Unified Process), han sido revisados y adaptados para su aplicación en las
entidades integrantes del Sistema Nacional de Informática por la Oficina Nacional de
Gobierno Electrónico e Informática – ONGEI de la Presidencia del Consejo de Ministros -
PCM. Es un instrumento útil para la sistematización de las actividades que dan soporte al
ciclo de vida del software. Incluye: Modelamiento del Negocio, Modelamiento de
Requerimientos, Modelamiento de Tecnología, Construcción, Pruebas e Implantación del
Sistema de Información
30 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Lección 4
Introducción al UML
4.1 ¿Qué es el UML?
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje,
basado en una notación gráfica, que permite: especificar, construir, visualizar y
documentar los elementos de un sistema software, así como para modelar los procesos
de negocios u otros sistemas no software (Jacobson, 2006).
Puede ser utilizado por cualquier metodología de desarrollo orientada a objetos. Este
lenguaje es el resultado de la unificación de los métodos de modelado orientados a
objetos de: Grady Booch, Jim Rumbaugh, Ivar Jacobson.
Un lenguaje de modelado permite expresar los distintos modelos (artefactos) que se
producen en el proceso de desarrollo de software.
Elementos Estructurales
Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura
4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de
responsabilidad.
Clase Figura 4.1 Elementos estructurales del UML
Nodo
Colaboración Caso de uso
Componente
Interfaz
31 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Elementos de comportamiento
Los elementos de comportamiento representan la parte dinámica del sistema, es decir el
comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.
Estado
Interacción
Mensaje
Elementos de agrupación
Los elementos de agrupación representan la parte organizativa del sistema. Incluye:
Paquete.
Paquete
Elementos de anotación
Los elementos de anotación representan la parte explicativa del sistema. Son
comentarios. Incluye: la nota
32 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Dependencia
Representa una relación semántica entre dos elementos, tal que un cambio en uno de
ellos (el independiente) puede afectar al otro (el dependiente).
Asociación
Representa una relación estructural que describe un conjunto de links, siendo un link una
conexión entre objetos.
Generalización
Representa una relación de generalización/especialización en la que el elemento
especializado (descendiente) se construye sobre la especificación del elemento
generalizado (ancestro)
Realización
Representa una relación semántica en la que un clasificador, tal como una interfaz o un
caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o una
colaboración, garantiza llevar a cabo.
33 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
34 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Lección 5
Introducción al RUP
5.1 ¿Qué es el RUP?
El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de
desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades
en una empresa de desarrollo, es decir define quién hace qué, cuándo y cómo (Jacobson,
2000).
Es un marco de trabajo genérico que puede especializarse. Es iterativo e incremental.
5.2 Elementos
5.2.2 Actividad
Es una unidad de trabajo que debe ser ejecutada. Una actividad es la más pequeña pieza
de trabajo que es relevante. No es razonable hacer actividades en forma parcial. Dividir el
trabajo de esta manera hace más fácil controlar el avance del proyecto. Es mejor saber
que hay 3 actividades completas de 5, que saber que llevamos el 60% de una actividad.
Ejemplos de actividades son Planificar una Iteración, Revisar el Diseño, Capturar
requisitos.
5.2.3 Artefacto
Es una pieza de información que es producida, modificada o usada en un proceso de
desarrollo de software. Un artefacto es algo que se produce e el curso del desarrollo de
un producto de software. Incluye el código fuente, los modelos, documentos y otros
productos del ciclo de vida. UML define la notación para representar la mayor parte de
los artefactos.
5.2.4 Modelo
Cada Trabajador, necesita una perspectiva del Sistema. El Artefacto más común para
representar una perspectiva es el Modelo. Los principales modelos de RUP son: Modelo
del negocio, modelo de casos de uso, modelo de diseño, modelo de implementación,
modelo de prueba.
El Modelo de Negocios es el modelo de los procesos de negocio y su medioambiente. Es
usado para generar requerimientos de los sistemas de información que lo soportan.
El Modelo de Casos de Uso es un modelo acerca de lo que el sistema debe hacer y su
medioambiente.
35 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
5.3 Fases
El RUP es un modelo de proceso del software dividido en cuatro fases: Inicio. Elaboración,
Construcción y Transición (Figura 5.2). Estas fases están mucho más relacionadas con el
funcionamiento de la organización que con aspectos técnicos de la implementación
36 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Al finalizar esta fase, se obtienen: Un modelo de los requerimientos del sistema (casos de
uso UML), Una descripción arquitectónica, Un plan de desarrollo del software,
5.4 Flujos
La perspectiva estática del RUP se centra en las actividades que tienen lugar durante el
proceso de desarrollo. Éstas se denominan flujos de trabajo en la descripción del RUP
(Figura 5.2).
Existen seis flujos de trabajo del proceso:
Modelado de negocio
Requerimientos
Análisis y diseño
Implementación
Pruebas
Implantación
Existen tres flujos de trabajo de soporte
Administración de cambios y configuración
Administración del proyecto
Entorno
Figura 5.2 Estructura del RUP, fases y flujos.
37 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Resumen
• Proceso de desarrollo de sistemas de información
• Un proceso de desarrollo es una guía acerca de las actividades y tareas necesarias para construir un
sistema de información. Es un marco de trabajo que define las tareas a realizar para desarrollar
software de alta calidad.
• Las fases genéricas de un proceso de desarrollo son: Definición, Desarrollo y Evolución.
• La fase de definición se centra en el “que”. Su propósito es identificar las necesidades o
requerimientos del cliente/usuario. Sus actividades son: Análisis del sistema, Requerimientos
de software, y Planificación del proyecto de software.
• La fase de desarrollo se centra en el “cómo”. Su propósito es descubrir cómo han de diseñarse
las estructuras de datos y la arquitectura del software, etc. Se realizan tres pasos concretos:
Diseño del Software, Codificación y Pruebas del software.
• La fase de evolución, también llamada fase de mantenimiento, se centra en el “cambio” que
va asociado a la Corrección, a la Adaptación y Mejora del software.
• Los modelos de proceso de desarrollo de software se clasifican en
• Modelo secuencial, se caracteriza porque las actividades del desarrollo progresan de manera
secuencial, una actividad no puede inicia sino a terminado la anterior.
• Modelos iterativos, se caracterizan porque las actividades se repiten de manera cíclica. Entre
los modelos iterativos podemos mencionar: Construcción de prototipos y Desarrollo Rápido de
Aplicaciones.
• Modelos evolutivos, se caracterizan porque son iterativos y en cada iteración se agrega nueva
funcionalidad (versiones) al sistema. Se puede mencionar al modelo incremental y al modelo
espiral.
• Una metodología representa el camino a seguir para desarrollar software o aplicaciones
informáticas de una manera sistemática, consiste de un conjunto de fases subdivididas en etapas,
actividades y tareas.
• Una tarea es una actividad elemental siguiendo algún procedimiento.
• El procedimiento es la definición de la forma de ejecutar la tarea.
• La técnica es la herramienta utilizada para aplicar un procedimiento; se pueden utilizar una o
varias.
• Una herramienta es el soporte software que apoya la aplicación de una técnica.
• Un producto es el resultado de cada fase, etapa o actividad de una metodología
• Introducción a UML
• UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una
notación gráfica, que permite: especificar, construir, visualizar y documentar los elementos de un
sistema software, así como para modelar los procesos de negocios u otros sistemas no software
• Un artefacto representa la información que es utilizada o producida durante un proceso de
desarrollo de software. Ejemplo: documento de especificación de requisitos, un modelo, un
programa.
• Un modelo es una representación abstracta de una especificación, un diseño o un sistema
desde un punto de vista particular. Representa uno o más diagramas. Ejemplos: modelo de
casos de uso, modelo de negocio.
• Un diagrama es una representación gráfica de una colección de elementos del modelo.
Ejemplos: diagrama de casos de uso, diagrama de clases.
• Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupación y de
anotación.
• Los elementos estructurales representan la parte estática del sistema. Se incluyen (figura 4.1):
Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de
responsabilidad.
• Los elementos de comportamiento representan la parte dinámica del sistema, es decir el
comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.
38 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
• Los elementos de agrupación representan la parte organizativa del sistema. Incluye: Paquete.
• Los elementos de anotación representan la parte explicativa del sistema. Son comentarios.
Incluye: la nota
• Las relaciones en UML representan los vínculos entre dos elementos del modelo. Incluye:
dependencia, asociación, generalización y realización.
• La dependencia representa una relación semántica entre dos elementos, tal que un cambio en
uno de ellos (el independiente) puede afectar al otro (el dependiente, clase activa,
componente, cadena de responsabilidad
• La asociación representa una relación estructural que describe un conjunto de links, siendo un
link una conexión entre objetos.
• La generalización representa una relación de generalización/especialización en la que el
elemento especializado (descendiente) se construye sobre la especificación del elemento
generalizado (ancestro)
• La realización representa una relación semántica en la que un clasificador, tal como una
interfaz o un caso de uso, especifica un “contrato” que otro clasificador, tal como una clase o
una colaboración, garantiza llevar a cabo.
• Los diagramas en UML, version2.0, son 13, divididos en diagramas estáticos y dinámicos.
• Los diagramas estáticos son: diagrama de clases, diagrama de objetos, diagrama de
componentes, diagrama de despliegue, diagrama de paquetes y diagrama de estructura.
• Los diagramas dinámicos son: diagrama de casos de uso, diagrama de secuencia, diagrama de
colaboración, diagrama de estado, diagrama de actividades, diagrama cronológico, diagrama
de interacciones.
• Introducción a RUP
• El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo
39 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Lectura
Técnicas de cuarta generación (*)
El término técnicas de cuarta generación (T4G) abarca un amplio espectro de herramientas de
software que tienen algo en común: todas facilitan al ingeniero del software la especificación de
algunas características del software a alto nivel. Luego, la herramienta genera automáticamente
el código fuente basándose en la especificación del técnico. Cada vez parece más evidente que
cuanto mayor sea el nivel en el que se especifique el software, más rápido se podrá construir el
programa. El paradigma T4G para la ingeniería del software se orienta hacia la posibilidad de
especificar el software usando formas de lenguaje especializado o notaciones gráficas que
describa el problema que hay que resolver en términos que los entienda el cliente. Actualmente,
un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o
algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de
datos, generación de informes, manejo de datos, interacción y definición de pantallas, generación
de códigos, capacidades gráficas de alto nivel y capacidades de hoja de cálculo, y generación
automatizada de HTML y lenguajes similares utilizados para la creación de sitios web usando
herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban
disponibles, pero sólo para ámbitos de aplicación muy específicos, pero actualmente los entornos
T4G se han extendido a todas las categorías de aplicaciones del software.
Al igual que otros paradigmas, T4G comienza con el paso de reunión de requisitos. Idealmente, el
cliente describe los requisitos, que son, a continuación, traducidos directamente a un prototipo
operativo. Sin embargo, en la práctica no se puede hacer eso. El cliente puede que no esté seguro
de lo que necesita; puede ser ambiguo en la especificación de hechos que le son conocidos, y
puede que no sea capaz o no esté dispuesto a especificar la información en la forma en que
puede aceptar una herramienta T4G. Por esta razón, el diálogo cliente-desarrollador descrito por
los otros paradigmas sigue siendo una parte esencial del enfoque T4G.
Para aplicaciones pequeñas, se puede ir directamente desde el paso de recolección de requisitos
al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G) o
un modelo comprimido de red de iconos gráficos. Sin embargo, es necesario un mayor esfuerzo
para desarrollar una estrategia de diseño para el sistema, incluso si se utiliza un L4G. El uso de
T4G sin diseño (para grandes proyectos) causará las mismas dificultades (poca calidad,
mantenimiento pobre, mala aceptación por el cliente) que se encuentran cuando se desarrolla
software mediante los enfoques convencionales.
La implementación mediante L4G permite, al que desarrolla el software, centrarse en la
representación de los resultados deseados, que es lo que se traduce automáticamente en un
código fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos
con información relevante y a la que el L4G pueda acceder rápidamente.
Para transformar una implementación T4G en un producto, el que lo desarrolla debe dirigir una
prueba completa, desarrollar con sentido una documentación y ejecutar el resto de las
actividades de integración que son también requeridas por otros paradigmas de ingeniería del
software. Además, el software desarrollado con T4G debe ser construido de forma que facilite la
realización del mantenimiento de forma expeditiva.
Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes.
Los defensores aducen reducciones drásticas en el tiempo de desarrollo del software y una
mejora significativa en la productividad de la gente que construye el software. Los detractores
aducen que las herramientas actuales de T4G no son más fáciles de utilizar que los lenguajes de
programación, que el código fuente producido por tales herramientas es «ineficiente» y que el
mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.
40 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Hay algún mérito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado
actual de los enfoques de T4G:
1. El uso de T4G es un enfoque viable para muchas de las diferentes áreas de aplicación.
Junto con las herramientas de ingeniería de software asistida por computadora (CASE) y
los generadores de código, T4G ofrece una solución fiable a muchos problemas del
software.
2. Los datos recogidos en compañías que usan T4G parecen indicar que el tiempo requerido
para producir software se reduce mucho para aplicaciones pequeñas y de tamaño medio,
y que la cantidad de análisis y diseño para las aplicaciones pequeñas también se reduce.
3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el
mismo o más tiempo de análisis, diseño y prueba (actividades de ingeniería del software),
para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la
eliminación de la codificación.
Resumiendo, las técnicas de cuarta generación ya se han convertido en una parte importante del
desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el
paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software.
41 Sistema a Distancia
Análisis de Sistemas - Unidad II César Luza Montero
Actividades
1. Realice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de
software, indicando criterios de comparación, ventajas y desventajas de cada una de ellas
por cada criterio.
2. Busque en internet herramientas de software libre para modelar con el UML 2.0. .
Autoevaluación
Responda las siguientes preguntas:
1. Un proceso de desarrollo es
2. Las fase de un proceso de desarrollo son:
3. Indique las características de los siguientes modelos de ciclo de vida:
a. Secuencial
b. Construcción de prototipos
c. Desarrollo rápido de aplicaciones
d. Incremental
e. Espiral
4. Una definición de metodología es
5. Un producto, técnica, herramientas son
6. El UML es
7. El RUP es
Exploración on-line
• ISO/IEC 12207
Pagina de la organización internacional para la estandarización, ISO
http://www.iso.org/iso/catalogue_detail.htm?csnumber=43447
• OMG UML
Pagina oficial del Object Management Group, sobre UML, proporciona información y recursos
para UML
http://www.uml.org/
• IBM - RUP
Pagina de IBM Rational Unified Process, que ofrece información y recursos sobre la
plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml
Referencias bibliográficas
• Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
• Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
• Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
42 Sistema a Distancia
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
TERCERA UNIDAD
EL MODELADO DE NEGOCIOS
43
43
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Lección 6
44
44
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Los casos de uso del negocio se clasifican en: Principales, de Soporte y de Gestión. Los casos
de uso del negocio principales son aquellos que están ligados directamente con la
realización del producto y/o la prestación del servicio para el Cliente. Los casos de uso del
negocio de soporte son aquellos que proporcionan apoyo a los procesos principales,
usualmente están relacionados con la gestión de recursos. Los casos de uso del negocio
de gestión son aquellos que están vinculados al ámbito de las responsabilidades de la
dirección, se relacionan con actividades de planificación y control.
Para identificar un caso de uso del negocio principal (proceso de negocio principal) es
necesario determinar el servicio o producto de la empresa que recibe el actor del
negocio. Para identificar un caso de uso de negocio de soporte (proceso de negocio de
soporte) es necesario determinar que se requiere para ofrecer los productos o servicios al
cliente. Para identificar casos de uso de negocio de gestión es necesario examinar las
actividades relacionadas con la gestión de la empresa en su conjunto.
Algunos ejemplos de Casos de uso del negocio son: Solicitar un pedido, Realizar Venta.
45
45
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Un trabajador del negocio (business worker) es alguien que realiza actividades dentro de
un caso de uso del negocio, interactúa con otros trabajadores del negocio y manipula
entidades del negocio.
La realización de un caso de uso del negocio puede incluir o se puede representar con:
Diagrama de actividades o Diagrama de Clases.
Diagrama de actividades
El Diagrama de actividades permite explorar el orden en que se realizan las actividades en
un caso de uso de negocio. Una actividad es una tarea manual o automatizada que
completa una unidad de trabajo.
Los elementos básicos de un diagrama de actividades son: Inicio, fin, actividad, transición,
barra de sincronización y bifurcación. En la figura 6.8 se observa un diagrama de actividades
básico, que se puede interpretar como sigue: el proceso se inicia con el llenado del
pedido, la flecha de transición entre llenar pedido y tramitar pedido significa que después
de la actividad llenar pedido sigue la actividad tramitar pedido. Terminado de tramitar el
pedido sigue analizar viabilidad cuyo resultado indica que si no es viable, se notifica el
rechazo y termina el flujo con rechazo; si es viable, en forma paralela se
46
46
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Inicio Rellenar
Pedido
Tramitar Analizar
Pedido Viabilidad
Fin NoOK
Notificar Ordenar
Aceptacion fabricacion
Planificar
Produccion
Fin OK
[copia]
z : Libro de citas
Reparar coche
o : Orden de reparación
Guardar en partes pendientes
[original]
p : Partes de trabajo
[pendiente]
47
47
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Recib e
pago con tarjeta Em pleado del m os tradoir
(f rom Trabajadores del negocio)
(f rom Entidades del negc cio)
pago
(f rom Entidades del negccio)
Pago en efectivo
(f rom Entidades del negc cio)
48
48
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Lección 7
Cliente Proveedor
49
49
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Regis trar pedido Fabricar producto Controlar almacen Comprar materia prima
Reducir tiem po en 20% Mantener s tock adecuado Reducir tasa errores a 0.5% Reducir generación orden com pra en 20%
Fabricar producto Reducir tas a errores a 0.5% Controlar alm acen Mantener s tock adecuado
(f rom Metas del negoc io)
(from Casos de uso del negoci o) (f rom Metas del negoc io) (from Casos de uso del negoci o)
50 Sistema a Distancia
50
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
1. El Cliente envía su pedido, por teléfono, por fax o por correo, al Dpto. de Ventas. El
pedido debe incluir la fecha de solicitud, datos del cliente y producto solicitado.
2. Un Empleado del Dpto. de Ventas revisa el pedido (completándolo, si es necesario).
Comienza su procesamiento enviándolo al Jefe Técnico, que está encargado de su
análisis.
3. El Jefe Técnico analiza la viabilidad del producto solicitado. Si el producto pedido está en
el catálogo, su fabricación es aceptada. En caso contrario, es considerado un producto
especial, y el Jefe Técnico estudia su fabricación: Si es viable, la fabricación del producto
especial es aceptada; Si no es viable, el producto especial no será fabricado.
4. Una vez estudiado el pedido completo, el Jefe Técnico informa al Dpto. de Ventas de la
aceptación o rechazo del producto pedido; Si el producto de un pedido ha sido aceptado,
se crea una orden de trabajo, a partir de una plantilla de fabricación (la estándar si el
producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si
éste no estaba en el catálogo). Cada orden de trabajo es enviada al Jefe de Producción, y
queda pendiente de su fabricación.
5. El Empleado del Dpto. de Ventas comunica al cliente el resultado final del análisis de su
pedido.
51 Sistema a Distancia
51
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Llenar pedido
p : Pedido
[propuesto]
Analizar viabilidad
x:
Pedido : Producto es pecial
Tramitar pedido
[ NO Viable ]
[ SI viable ]
: Plantilla de fabricacion
Informar rechazo
r : Pedido
[Rechazado]
Informar aceptacion
a : Pedido
52 Sistema a Distancia
52
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Resumen
Conceptos asociados al modelado del negocio
El modelado del negocio es una técnica para representar proceso de negocio, tiene dos
perspectivas: externa (modelo de casos de uso) e interna (modelo de análisis del negocio).
El modelo de casos de uso del negocio representa la forma en que la empresa interactúa con su
entorno. Incluye: actores, casos de uso del negocio.
o Un actor de negocio representa un rol que alguien o algo desempeña en relación al
negocio.
o Un caso de uso de negocio representa un conjunto de secuencia de acciones que un
negocio realiza para producir un resultado observable para un actor de negocio.
o Un diagrama de caso de uso de negocio muestra actores de negocio, casos de uso de
negocio y las relaciones entre ellos.
El modelo de análisis del negocio describe la realización de los casos de uso del negocio mediante
interacción de los trabajadores del negocio y las entidades del negocio.
o Un trabajador de negocio representa un rol que se ejecuta en la realización de un caso de
uso del negocio.
o Una entidad de negocio representa una pieza de información significativa y persistente
que es manipulado por trabajadores de negocio o actores de negocio.
o Una realización de casos de uso de negocio describe como los trabajadores y entidades del
negocio colaboran para desarrollar un caso de uso del negocio.
Proceso de modelado del negocio
Elaboración del modelo de casos de uso del negocio
o Identificar actores de negocio
o Identificar casos de uso del negocio
o Elaborar diagrama de casos de uso del negocio
Elaboración del modelo de análisis del negocio
o Identificar trabajador de negocio
o Identificar entidad de negocio
o Construir realización de casos de uso del negocio
Con Diagrama de actividades
Con diagrama de clases de análisis del negocio
53 Sistema a Distancia
53
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Lectura
Manifiesto de Reglas de Negocio (*)
Los Principios de la Independencia de las Reglas
The Business Rules Group
Artículo 1. Los requisitos como elementos principales, nunca como secundarios
1.1. Las reglas son un ciudadano de primera clase en el mundo de los Requisitos.
1.2. Las reglas son esenciales para los modelos de negocio y para los modelos de tecnología, y una
parte separada y especifica de los mismos.
Artículo 2. Independientes de los procesos y no contenidas en ellos
1.1. Las reglas son restricciones explicitas de comportamiento y/o proporcionan soporte para la
dirección de las actividades de negocio.
1.2. Las reglas no son procesos ni procedimientos. Y por tanto no deben estar contenidas en ninguno
de ellos.
1.3. Las reglas se aplican a lo largo de los procesos y procedimientos. Debe existir un corpus coherente
de reglas que se aplique sistemáticamente en todas las áreas de actividad del negocio.
Artículo 3. Proporcionar conocimiento meditado, no un sub-producto
1.1. Las reglas se construyen sobre hechos, y los hechos sobre conceptos tal y como son expresados
mediante términos.
1.2. Los términos expresan conceptos de negocio; los hechos realizan afirmaciones sobre estos
conceptos; las reglas restringen y apoyan estos hechos.
1.3. Las reglas deben ser explicitas. No se debe asumir ninguna regla sobre ningún concepto o hecho.
1.4. Las reglas son los fundamentos que definen lo que el negocio sabe de si mismo- es decir son
conocimiento básico de negocio.
1.5. Las reglas necesitan ser alimentadas, protegidas y gestionadas.
Artículo 4. Declarativas, no de procedimiento
4.1 Las reglas deben expresarse de forma declarativa en sentencias de lenguaje natural, por la
audiencia conocedora del negocio.
4.2 Si algo no puede ser expresado claramente, entonces no es una Regla.
4.3 Una serie de enunciados solo es declarativa si no contiene una secuencia implícita.
4.4 Cualquier enunciado de reglas que necesite de otros elementos que no sean términos o hechos,
revelan hipótesis sobre la implementación de un sistema.
4.5 Una regla es distinta del nivel de cumplimiento definido para ella. La regla y su nivel de
cumplimiento son dos asuntos diferentes.
4.6 Las reglas deben definirse independientemente de la quien tiene la responsabilidad de su
cumplimiento, y de donde, cuando o como se refuerzan.
4.7 Las excepciones a las reglas se definen mediante otras reglas.
Artículo 5. Expresiones bien formadas, no expresiones creadas con fines específicas para un caso
1.1 Las reglas de negocio se deben expresar demanera que pueda ser validada su exactitud por el
personal conocedor del negocio.
1.2 Las reglas de negocio se deben expresar de manera que se pueda verificar recíprocamente su
coherencia.
1.3 Las lógicas formales, como la lógica de predicados, son fundamentales para la expresión formal de
reglas en términos de negocio, así como para las tecnologías que implementan dichas reglas.
Artículo 6. Arquitectura basada en las reglas, no una implementación indirecta
6.1 Un sistema basado en reglas de negocio se construye intencionadamente para permitir el cambio
continuo de las reglas de negocio. La plataforma sobre la que el sistema se ejecuta debe soportar
esta evolución.
6.2 Es mejor ejecutar las reglas directamente – por ejemplo utilizando un motor de reglas – antes que
transcribirlas en alguna forma embebida dentro de un procedimiento.
6.3 Un sistema de reglas de negocio siempre debe ser capaz de explicar el razonamiento por el cual
llega a una conclusión o emprende una acción.
54 Sistema a Distancia
54
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
6.4 Las reglas se basan en los valores ciertos. La forma en la que certeza de una regla se determina, se
mantiene oculta a quienes la utilizan.
6.5 La relación entre eventos y reglas es generalmente de muchos-a-muchos.
Artículo 7. Procesos guiados por reglas, no programación basada en excepciones
7.1 Las reglas definen el límite entre actividad de negocio aceptable y no aceptable.
7.2 Las Reglas requieren a menudo de una gestión especial o especifica de las violaciones detectadas.
Cualquier actividad derivada de la violación de una regla es una actividad como cualquier otra.
7.3 Para asegurar la máxima consistencia y reutilización, el tratamiento de las actividades de negocio
no aceptables, debe separarse de la gestión de actividades de negocio aceptables.
Artículo 8. Al servicio del negocio, no al de la tecnología
8.1 Las Reglas tratan sobre las prácticas de la gestión y gobierno del negocio, por lo tanto son
motivadas por las metas y los objetivos de negocio y se les da forma a través de varios
factores internos y externos a la empresa.
8.2 Las reglas suponen siempre un coste a la empresa.
8.3 Este coste de la aplicación de las reglas debe valorarse y balancearse, teniendo en cuenta
los riesgos asumidos por el negocio, y las oportunidades perdidas en caso de no aplicarlas.
8.4 “Más reglas” no es mejor, la abundancia de reglas no beneficia a su aplicación.
Normalmente es mejor un número limitado de reglas bien reflexionadas.
8.5 Un sistema eficaz puede estar basado en un pequeño número de reglas. Adicionalmente,
se pueden añadir reglas más discriminatorias, por las que ha medida que pasa el tiempo el
sistema mejore y se hace más inteligente.
Artículo 9. “De, por y para” el personal de negocio. No “de, por y para” el personal de IT.
9.1 Las reglas deben provenir del personal con conocimiento de negocio.
9.2 Los expertos de negocio debe tener disponibles herramientas que les ayuden a formular, validar y
gestionar reglas.
9.3 Los expertos de negocio deben tener disponibles herramientas que les ayuden a verificar la
coherencia reciproca entre las reglas de negocio.
Artículo 10. Gestionando la lógica de negocio, no las plataformas de Hardware/Software
1.1 Las reglas de negocio son un patrimonio vital del negocio.
1.2 A largo plazo, las reglas son más importantes para el negocio que las plataformas
Hardware/Software.
1.3 Las reglas de negocio deben organizarse y salvaguardarse de forma que puedan ser redesplegadas
a nuevas plataformas de Hardware/Software.
1.4 Las reglas, y la habilidad para cambiarlas de forma eficaz, son factores clave para mejorar la
adaptabilidad de las empresas.
55 Sistema a Distancia
55
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Actividades
Elaborar el Modelo del Negocio considerando la siguiente descripción:
56 Sistema a Distancia
56
Análisis de Sistemas - Unidad III Dr. Francisco Ramírez V
Autoevaluación
1 El modelado del negocio es
2 Los elementos del modelo de caso de uso del negocio son
3 Un actor de negocio es
4 Un caso de uso de negocio es
5 Los elementos del modelo de análisis del negocio son
6 Un trabajador de negocio es
7 Una entidad de negocio es
Exploración on-line
IBM - RUP
Pagina de IBM Rational Unified Process, que ofrece información y recursos sobre la
plataforma de proceso de desarrollo de software configurable
http://www-01.ibm.com/software/pe/rational/rup.shtml
Referencias bibliográficas
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
57 Sistema a Distancia
57
CUARTA UNIDAD
EL MODELADO DE DOMINIO
1
Lección 8
8.2 Atributo
Una clase tiene una serie de características o propiedades, por ejemplo ASIGNATURA
tiene código, nombre, créditos, horas de teoría, horas de practica; a estas propiedades se
le conoce como atributos de la clases. Un atributo es una propiedad de una clase que
describe un rango de valores que la propiedad podrá contener en los objetos de la clase
(Rumbaugh, 1996)..
Podemos decir que una clase representa un conjunto de objetos con las mismos atributos
y un objeto es una instancia de una clase, es decir es una entidad que tiene valores
específicos para cada uno de los atributos de la clase.
Por ejemplo, la clase AUTOMOVIL, tiene como atributos: número de placa, color, modelo,
número de puertas, año, entre otros. Un objeto, de la clase AUTOMOVIL, es el auto de
placa SGD345, color azul, modelo Station Wagon, con cuatro puertas, del año 2000. Otro
objeto es el auto de placa ERG237, negro, deportivo, 4 puertas, año 2009.
8.3 Operación
Una clase tiene un comportamiento que es definido por las operaciones o
responsabilidades que la clase puede realizar. Una operación es algo que la clase puede
realizar o que otra clase puede hacer a una clase. Es una función o transformación que se
puede aplicar o que puede ser aplicada por los objetos de una clase (Rumbaugh, 1996)..
Por ejemplo, algunas operaciones de la clase automóvil pueden ser: Encender, Apagar,
Acelerar, Frenar.
2
8.4 Asociación y Enlace
Las entidades o cosas del mundo real se relacionan con otras entidades; a las relaciones
entre objetos se les llama enlaces y a las relaciones entre clases se les llama asociaciones
(Rumbaugh, 1996).
Mediante la abstracción de asociación se vincula dos o más clases, creándose un
elemento de tipo distinto (Vinculo).
Por ejemplo, “Docente dicta Asignatura”, es una asociación entre la clase docente y la
clase asignatura. “Francisco Ramírez dicta Análisis de sistemas” es un enlace entre los
objetos Francisco Ramírez y Análisis de sistemas.
INGENIERO
Una Clase ES UN TIPO DE otra
La Agregación representa la relación entre clases, donde algunas de ellas son componentes
de otra. Por ejemplo, las clases CPU, TECLADO, MOUSE, MONITOR son componentes de la
clase COMPUTADORA; en otras palabras, la clase COMPUTADORA está formada por las
clases CPU, TECLADO, MOUSE Y MONITOR (figura 8.2).
Mediante la agregación se construye una nueva clase o tipo o categoría de objetos a
partir de un conjunto de otras clases denominadas componentes o partes. La agregación
define una nueva clase de objetos a partir de un conjunto de clases (otras, no
necesariamente distintas) que representan sus partes componente.
Figura 8.2 Ejemplo de Agregación
CPU AGREGACIÓN
MOUSE
COMPUTADOR
MONITOR
TECLADO
3
8.6 ¿Qué es el modelo de domino?
El Modelo de dominio es un modelo conceptual que muestra clases conceptuales de
objetos significativos en un dominio de problema. Las clases conceptuales no muestran
componentes software, ni clases software, ni responsabilidades (Larman, 1999).
Por ejemplo, algunas clases conceptuales del dominio de la Gestión Académica son:
ALUMNO, DOCENTE, ASIGNATURA y HORARIO.
El modelo de dominio se puede documentar con un Diagrama de Clases.
1 1
1 Capturada-en
A lb erga
P agada-m edian te 1
1.. *
1 Registro
P ago
cantidad
Clase
Para efectos del modelo de dominio, una clase puede considerarse en términos de:
Símbolo, palabras o imágenes que representan a la clase;
Definición del concepto, descripción textual del significado de la clase y
Extensión: conjunto de objetos que pertenecen a la clase.
Por ejemplo, considere la clase Venta del diagrama de clases de la figura 8.4.
4
El símbolo del concepto es un rectángulo dividió en tres partes, la primera es el nombre
de la clase, la segunda los atributos y la tercera las operaciones.
Figura 8.4 Clase
Venta
fecha
hora
La definición del concepto es: Una venta representa el hecho de una transacción de
compra, sucede un día y en una hora.
La extensión es el conjunto de todas las ventas realizadas en la tienda.
Atributo
Para efectos del modelo de dominio se incluyen aquellos atributos para los que los
requisitos indican la necesidad de registrar su información.
Por ejemplo, un recibo recoge la información de una venta, incluyendo fecha y hora. La
Gerencia de la Tienda quiere conocer fecha y hora de las ventas, la clase Venta necesita
los atributos fecha y hora.
Según la notación UML, los atributos se muestran en el segundo compartimento del
rectángulo de la clase.
Figura 8.5 Atributos
Venta
fecha
hora
Asociación
La asociación se representa con una línea que une las clases relacionadas. En el siguiente
ejemplo, se muestra la relación entre las clases ALUMNO y FACULTAD; la semántica
señala que un alumno pertenece a una única facultad y una facultad tiene muchos
alumnos.
Figura 8.6 Asociación
5
un solo objeto de Facultad, y un objeto de Facultad está vinculado con varios objetos de
ALUMNO”.
La multiplicidad permite representar, en el diagrama de clases, las reglas del negocio
definidas en el dominio del problema. Las categorías típicas de multiplicidad son: “Uno a
Uno”, “Uno a Muchos” y “Muchos a Muchos”. En la figura 8.7 se aprecia algunos tipos de
multiplicidad.
Figura 8.7 Tipos de multiplicidad
Clase-Asociación
En algunas ocasiones es necesario representar propiedades propias de la asociación; para
tal efecto, se crea una clase especial llamada Clase-Asociación. Por ejemplo,
consideremos la asociación ALUMNO matriculado en ASIGNATURA, la multiplicidad de
esta asociación es de “muchos a muchos”, en efecto, un alumno puede llevar varias
asignaturas y una asignatura es llevada por varios alumnos. Entonces, la nota promedio
de un alumno en una asignatura corresponde a la asociación; pues si se coloca como
atributo de alumno, no se sabría de qué asignatura es; si se coloca como atributo de
asignatura, no se sabría de qué alumno es, entonces, se crea una clase especial llamada
clase asociación MATRICULA en el que se coloca el atributo nota promedio.
La representación de una clase asociación se hace con una línea discontinua que une la
asociación con la clase generada. (figura 8.8).
Figura 8.8 Ejemplo de Clase-Asociación
Generalización
6
La generalización se representa a través de una línea recta entre las clases subtipos
terminados en un triángulo blanco en el extremo cercano a la clase generalizada. Por
ejemplo, en la figura 8.9, ANFIBIO, MAMÍFERO y REPTIL son tipos de ANIMAL. A su vez,
CABALLO es un tipo de MAMÍFERO.
La Generalización puede encontrarse en aquellas clases que tienen ciertos atributos y
operaciones en común. En ese caso se crea una clase nueva que asume dicho
comportamiento común.
Figura 8.9 Ejemplo de Generalización
Agregación
La agregación se representa a través de una línea recta entre las clases “partes” terminados
en un rombo en el extremo cercano a la clase “todo”. Por ejemplo, en la figura 8.10,
MONITOR, CASES, TECLADO y MOUSE son partes o componentes de COMPUTADORA. A su
vez, CASES está formado por CPU, RAM,VENTILADOR.
Figura 8.10 Ejemplo de Agregación
7
Lección 9
Una empresa recién formada se dedica a integrar partes para formar productos con la intención
de vender el valor agregado de la integración. Con el objetivo de apoyar sus actividades,
mediante una aplicación informática, se ha obtenido las siguientes reglas semánticas:
Un producto tiene un nombre y un precio base. Un producto se forma con muchas partes y
cada parte puede formar muchos productos. La definición de cada producto especifica qué
cantidad de cada parte forma a un producto dado.
Un vendedor tiene un apellido, nombre y un porcentual de comisión. Tanto un cliente como un
proveedor tienen los datos de todo agente comercial; éstos son: cuit, razón social, e-mail,
teléfono y dirección. Además, un proveedor tiene un plazo de pago y un cliente un porcentual
de descuento.
Un parte puede ser comprado a muchos proveedores y un proveedor puede proveer muchas
partes. Cada compra de un parte tiene una fecha y una cantidad. Una venta se realiza entre
cualquier vendedor y cualquier cliente, y éste puede comprar cualquier producto. De una
venta se quiere saber su fecha.
No se pueden vender productos que estén formados por una única parte, esto es, no se
permite vender productos sin elaborar.
8
9.2 Identificando Asociaciones
Se establecen las asociaciones según las reglas del negocio en el dominio del problema, se
puede considerar como estrategia para identificar asociaciones la selección de verbos en
la descripción del problema. Se le agrega la multiplicidad correcta. También se puede
representar la relación " es parte de" o agregación.
En nuestro caso, las asociaciones identificadas son:
producto 1..n se forma 1..n parte
vendedor
1..n 1..n
se vende
agenteComercial Se compra
1..n
1..n
cliente
proveedor
1..n 1..n
cliente proveedor
porcDesc plazoPago
9
9.4 Identificar relaciones de generalización
Se organiza y simplifica el modelo usando el principio de herencia; es decir, se puede
generalizar los aspectos comunes de las clases existentes construyendo una superclase, o
se puede especializar una clase en varias subclases.
Para nuestro ejemplo se establece relación de generalización entre agente comercia con
cliente y proveedor:
1..n
1..n
cliente proveedor
porcDesc plazoPago
10
Resumen
11
Lectura
Desarrollo de un modelo de dominio (*)
El modelado de dominio se realiza habitualmente en reuniones organizadas por los analistas del
dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. Para
formar un equipo eficaz, estas reuniones deberían incluir tanto a expertos del dominio como a gente
con experiencia en modelado.
El objetivo del modelado del dominio es com prender y describir las clases más importantes
dentro del contexto del sistema. Los dominios de tamaño moderado normalmente requieren
entre 10 y 50 de esas clases. Los dominios más grandes pueden requerir muchas más.
Los restantes cientos de clases candidatas que los analistas pueden extraer del dominio se
guardan como definiciones en un glosario de términos, de otra manera, el modelo de dominio se
hará demasiado grande y requeriría más esfuerzo del necesario para esta parte del proceso.
Algunas veces, como en los dominios del negocio muy pequeños, no es necesario desarrollar un
modelo de objetos para el dominios; en su lugar, puede ser suficiente un glosario de términos.
El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores, y otros
interesados a utilizar un vocabulario común. La terminología común es necesaria para compartir
el conocimiento con los otros. Cuando abunda la confusión, el proceso de ingeniería se hace
difícil, si no imposible. Para construir un sistema software de cualquier tamaño, los ingenieros de
hoy en día deben “fundir” el lenguaje de todos los participantes en uno solo consistente.
Por último, es necesario una llamada de atención sobre el modelo de dominio. Puede ser bastante
fácil el comenzar modelando las partes internas de un sistema y no su contexto. Por ejemplo,
algunos objetos del dominio podrían tener una representación inmediata en el sistema, y algunos
analistas del dominio podrían a su vez caer en la trampa de especificar los detalles relativos a esta
representación. En casos como éstos, es muy importante recordar que el objetivo del modelado
del dominio es contribuir a la comprensión del contexto del sistema, y por lo tanto también
contribuir a la comprensión de los requisitos del sistema que se desprenden de este contexto. En
otras palabras, el modelado del dominio debería contribuir a una compresión del problema que
se supone que el sistema resuelve en relación a su contexto. El modo interno por el cual el
sistema resuelve éste problema se trata en los siguientes flujos de análisis, diseño e
implementación.
12
Actividades
Desarrollar el modelo de dominio para el siguiente caso
13
Autoevaluación
Conteste las siguientes preguntas
1. La diferencia entre clase y objeto es
2. Proporciones una ejemplo de clase con algunos de sus atributos , y tres ejemplos de objetos
de dicha clases
3. Una clase conceptual es
4. La diferencia entre enlace y asociación es
5. La diferencia entre generalización y agregación es
6. El modelo de domino es
7. Un diagrama de clases es
8. La multiplicidad de una asociación representa
9. Una clase-asociación es
Exploración on-line
Portal del producto IBM Rational Modeler
http://www-01.ibm.com/software/awdtools/modeler/
Referencias bibliográficas
Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
14
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
QUINTA UNIDAD
72
72
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lección 10
73
73
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
El sistema permitirá a los profesores: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Registrar y
modificar las notas de los estudiantes a su cargo, Cerrar un curso
El sistema permitirá a los estudiantes: Consultar los horarios de sus cursos, Consultar la
programación de los exámenes, Actualizar y ver su información personal, Consultar notas
de un curso.
74
74
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Performance (Desempeño), se refieren a las características de rendimiento del sistem.
Incluye tiempos de respuesta específicos. Por ejemplo: Tiempo de respuesta para una
transacción (promedio, máximo); Transacciones por segundo; Capacidad, como por
ejemplo el número de clientes o transacciones que el sistema puede soportar; Modos de
degradación, esto es, cual es el modo aceptable de funcionamiento cuando el sistema ha
sido degradado de alguna manera; Utilización de recursos: memoria, disco,
comunicaciones, etc.
Supportability (Capacidad de Soporte), son requerimientos que refuerzan el soporte y
mantenimiento del sistema que está siendo construido, incluyendo normas de codificación,
convenciones de nombres, librerías, acceso para mantenimiento, utilidades de
mantenimiento si las hay. Como requerimiento que ayuda al mantenimiento se debe hacer
referencia al uso de nomenclatura común para el desarrollo del sistema, y a la metodología
de desarrollo.
75
75
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
1.6.1 Entrevistas
Esta técnica es adecuada para la primera toma de contacto. Es conveniente comenzar por
preguntas de contexto libre, para entender: el problema, a las personas interesadas en la
solución, naturaleza de ésta, y lograr efectividad de la reunión.
Ejemplos de preguntas centradas en el cliente, los objetivos globales y beneficios
¿Quién solicita el trabajo?
¿Quién utilizará la solución?
¿Cuál será el beneficio económico de una buena solución?
¿Existen otras alternativas a esta solución?
76
76
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
1.6.2 JAD
El Diseño en Conjunto de Aplicaciones (JAD, “Joint Application Design”) fue desarrollado
por IBM a finales de los setenta. Es una sesión de trabajo con participación de todos los
involucrados. El resultado de la sesión es un documento de especificación que incluye
definiciones de elementos de datos, flujos de trabajo y pantallas de interfaz.
El resultado de una sesión JAD representa un acuerdo entre usuarios, clientes y
desarrolladores y minimiza los cambios posteriores de requerimientos.
Las actividades de la sesión JAD son: Definición del proyecto, Investigación, preparación,
Sesión, preparación del documento final.
Definición del proyecto: el coordinador se entrevista con gerentes y clientes para
determinar objetivos y alcance del proyecto. Se elabora la “guía de definición
administrativa”.
Investigación: se entrevista a usuarios y se recopila información del dominio, descripción
de flujos de trabajo y asuntos a tratar en la reunión. Se elabora la “agenda de sesión” y la
“especificación preliminar”.
Preparación: el coordinador elabora un “documento de trabajo” o primer borrador del
documento final.
Sesión: el coordinador guía al equipo para crear la especificación del sistema en una
reunión que puede durar varios días. Se definen los flujos de trabajo, elementos de datos,
pantallas, informes,... Las decisiones se documentan en unos formularios.
Preparación de documento final: el coordinador prepara el “documento final” usando los
“formularios” y se distribuye a los asistentes para su revisión. Se realiza una reunión para
discutir revisiones y finalizar el documento.
77
77
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lección 11
11.2 Actor
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él. Una instancia de actor puede ser un individuo o un sistema
externo. La notación UML para el actor se muestra en la figura 11.1.
Por ejemplo, en el Sistema de Académico de la universidad, los actores pueden ser:
Secretario Académico, Alumno y Docente. Todos ellos interactúan con el sistema a través
de alguna de sus funcionalidades. Nótese que el nombre del actor represente el rol que
desempeñan grupos de usuarios, por ejemplo el rol alumno representa a todos los
alumnos; un alumno particular representa una instancia del actor alumno.
78
78
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
79
79
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor. Establecen lo que siempre debe cumplirse antes de comenzar un escenario en un
caso de uso. Normalmente implica que un escenario de otro caso de uso se ha
completado exitosamente. Estas deben redactarse en tiempo verbal pasado. Por ejemplo:
El usuario ha sido aceptado en el sistema con el rol de profesor.
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito. Estas deben redactarse en tiempo verbal pasado. Por
ejemplo: Se ha registrado en el sistema las notas de los alumnos.
El flujo básico, es la descripción narrativa de lo que debe ocurrir cuando los actores
interactúan con el sistema para satisfacer la meta u objetivo propuesto, se consideran los
pasos normales, no incluye las alternativas o variaciones.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Ejemplo de flujo básico:
1. El Caso de uso comienza cuando el profesor indica “registrar notas.”
2. El sistema muestra un formulario de validación de ingreso al sistema.
3. El usuario ingresa su código y su contraseña.
4. El sistema muestra los cursos asignados al profesor.
5. El profesor selecciona el curso.
6. El sistema muestra un listado de los estudiantes con sus notas.
7. El profesor selecciona el estudiante e ingresa la nota de práctica, del parcial, del
examen final y la nota final. Se repite para cada estudiante.
8. El profesor indica “guardar”.
9. El sistema valida toda la información y muestra un mensaje de confirmación y el
Caso de uso finaliza.
80 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
U suario
Mantener información del profesor
(f rom Actors )
Lección 12
acerca de las ocurrencias del sistema? Las respuestas a estas preguntas reflejan
funcionalidades del sistema para cada actor.
En nuestro caso, el actor Encargado de vuelo debe: Mantener información de unidades,
Registrar vuelo de carga y Registrar vuelo de pasajeros. El Gerente debe: Mantener
información de pilotos y Consultar vuelos por piloto. El Empleado de Ventas: Mantener
información de pasajeros, Registrar reserva de vuelo, Registrar confirmación de vuelo y
Consultar pasajeros que tomaron vuelo.
Mantener información de pilotos Consultar vuelos por pilotos Mantener información de pasajeros
Resumen
Conceptos asociados a los requerimientos
Un requerimiento es una condición o capacidad a la que debe ajustarse el sistema que se
construye. Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de éste
El requerimiento o requisito funcional describe que debe hacer el sistema respecto a su entorno.
Un requerimiento no funcional describe atributos del sistema o del ambiente en donde éste se
desarrolla. Pueden ser de: usabilidad, fiabilidad, desempeño, capacidad de soporte.
La entrevista es una técnica para obtener requerimientos usados en la primera toma de
contactos con los usuarios-clientes.
El diseño conjunto de aplicaciones, Joint Application Design (JAD) es una sesión con
participación de todos los involucrados, cuyo resultado es un documento de
especificación.
Conceptos asociados al modelo de casos de uso
El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del
sistema en forma de Casos de uso.
Un actor define un conjunto coherente de roles que los usuarios del sistema pueden jugar
cuando interactúan con él.
Un caso de uso define un conjunto de escenarios de casos de uso. Un escenario es una
secuencia de acciones e interacciones entre el actor y el sistema, que proporciona valor a
un actor particular.
Las precondiciones, son las restricciones que deben cumplirse para que el caso de uso se
inicie, se definen relativas al sistema no a su entorno, debe ser estados observables por el
actor
Las poscondiciones, son las condiciones que deben cumplirse para indicar que el caso de
uso ha terminado con éxito; establecen lo que debe cumplirse cuando el caso de uso
termina, son la garantía de éxito.
Los flujos alternativos, refleja las diferentes situaciones que provocan una desviación del
flujo básico de eventos, se consideran, condiciones anormales, extremas, ocasionales,
condiciones de error o violaciones de reglas.
Un diagrama de caso de uso muestra los actores los casos de uso y las relaciones entre ellos.
Proceso de construcción del modelo de casos de uso
Identificación de actores
Identificación de casos de uso
Elaboración de descripción de casos de uso
Elaboración de diagrama de casos de uso
86 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Lectura
Crear el diseño lógico de una interfaz de usuario (*)
Cuando los actores interactúan con el sistema, utilizaran y manipularan elementos de interfaces
de usuario que representan atributos (de los casos de uso). A menudo estos son términos del
glosario (por ejemplo, balance de cuenta, fecha de vencimiento y titular de cuenta). Los actores
pueden experimentar estos elementos de las interfaces de usuario como iconos, listas de elementos
u objetos en un mapa 2D, y pueden manipularlos por selección, arrastre o hablando con ellos. El
diseñador de interfaces de usuario identifica y especifica estos elementos actor por actor,
recorriendo todos los casos de uso a los que el actor puede acceder, e identificando los elementos
apropiados de la interfaz de usuario para cada caso de uso. Un único elemento de interfaz de usuario
puede intervenir en muchos casos de uso, desempeñando un papel diferente en cada uno. Así, los
elementos de la interfaz de usuarios pueden diseñarse para jugar varios roles. Deberíamos
responder a las siguientes preguntas por cada actor:
¿Qué elementos de interfaz de usuario se necesitan para posibilitar el caso de uso?
¿Cómo deberían relacionarse unos con otros?
¿Cómo se utilizaran en los diferentes casos de uso?
¿Cuál debería ser su apariencia?
¿Cómo deberían manipularse?
Para determinar qué elementos de interfaz de usuario necesitan ser accesibles al actor en cada caso
de uso, podemos contestar las siguientes preguntas:
¿Qué clases de dominio, entidades del negocio o unidades de trabajo son adecuados
como elementos de la interfaz de usuario para cada caso de uso?
¿Con qué elementos de la interfaz de usuario va a trabajar el actor?
¿Qué acciones puede invocar el actor, y qué decisiones puede tomar?
¿Qué guía o información va a necesitar el actor antes de invocar cada acción de los casos
de uso?
¿Qué información debe proporcionar el actor al sistema?
¿Qué información debe proporcionar el sistema al actor?
¿Cuáles son los valores medios de todos los parámetros de entrada o salida? Por ejemplo,
¿Cuántas facturas manejarán habitualmente un actor durante una sesión y cuál es el saldo
medio de la cuenta? Necesitamos estimaciones aproximadas de estas cosas porque así se
optimizará la interfaz gráfica de usuario para ellas (incluso aunque tengamos que permitir
un rango suficientemente grande).
Una forma práctica de trabajo es representar los elementos de la interfaz de usuario mediante notas
adhesivas, pegadas en una pizarra, y ordenadas para ilustrar la apariencia de la interfaz de usuario.
Seguidamente, los diseñadores de interfaces de usuario describen cómo pueden utilizar los actores
estos elementos cuando trabajen con los caso de uso. La ventaja de utilizar notas adhesivas es que
pueden representar la cantidad necesario a de datos. Además, las notas adhesivas tampoco parecen
permanentes .es fácil moverlas o simplemente eliminarlas-, lo que hace que el usuario se sienta
cómodo proponiendo cambios.
87 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Actividades
1. Desarrollar el modelo de casos de uso para el siguiente sistema para una agencia de alquiler
de autos
Para la segunda etapa de este proyecto se van a incorporar, al sistema, facilidades para
hacer reservas telefónicas. En este caso, el Empleado de Atención al Público tomará los
datos del cliente, la fecha del alquiler, días por los que se va a alquilar y vehículo que reserva.
Una reserva puede ser cancelada con hasta 48 horas de anticipación. Los clientes que hagan
reservas y no retiren el alquiler, no podrán efectuar nuevas reservas ni alquileres.
Al final de cada jornada, el Encargado de Autos lanzara un proceso que analizase las reservas
para el próximo día y marque los autos que corresponda como reservados.
88 Sistema a Distancia
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
Autoevaluación
1. Un requerimiento es:
2. Las diferencias entre un requerimiento funcional y no funciona son:
3. Los requerimientos se caracterizan por:
4. Cuando usaría las técnicas de entrevista y JAD
5. El modelo de casos de uso representa
6. El actor es
7. El caso de uso es
8. Un escenario de caso de uso es
9. Una precondición es
10. Una poscondición es
11. La diferencia entre flujo básico y flujo normal es
Exploración on-line
Sitio de Alistair Cockburn, sobre recursos e información de casos de uso
http://alistair.cockburn.us/
Referencias bibliográficas
IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology
–Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
Jacobson,I., et al, (1993). Object-Oriented Software Engineering: A Use case Driven Approach.
USA. Addison Wesley.
Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial Pearson.
Análisis de Sistemas - Unidad V Dr. Francisco Ramirez V.
Ramire
GLOSARIO
Actividad Es una unidad de trabajo que debe ser ejecutada en un proceso de desarrollo de
software.
Artefacto Es una pieza de información que es producida, modificada o usada en un proceso
de desarrollo de software.
Flujo de trabajo Es una secuencia de actividades que produce un resultado valioso, define una
lista de actividades, trabajadores y artefactos.
Metodología Es el conjunto de procedimientos, técnicas, herramientas, y un soporte
documental que ayuda a los desarrolladores a realizar nuevo software
Modelo de análisis de negocios Describe la realización de los casos de uso del negocio
mediante la interacción de los trabajadores del negocio y las entidades del negocio.
Modelo de casos de uso Es un modelo que describe los requerimientos funcionales del
sistema en forma de casos de uso.
Modelo de casos de uso del negocio Es una representación de la forma en que la empresa
interactúa con su entorno.
Modelo de dominio Es un modelo conceptual que muestra clases conceptuales de objetos
significativos en un dominio de problema. Las clases conceptuales no muestran componentes
software, ni clases software, ni responsabilidades
Organización Sistema compuesto por un conjunto de personas, actividades y recursos,
distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a
ciertas reglas de división del trabajo y comunicación que interactúan para producir bienes o
servicios
Proceso de desarrollo Es una guía acerca de las actividades y tareas necesarias para construir
un sistema de información.
Proceso de negocio Conjunto de actividades que toman uno o más imputs crean un outputs
de valor para el cliente.
RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de
software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de
desarrollo, es decir define quién hace qué, cuándo y cómo.
Trabajador Es un rol que debe ser realizada por una persona o equipo dentro de un proceso de
desarrollo de software..
Sistema de información Conjunto de componentes hardware, software, base de datos,
procedimientos y personas, que permiten capturar, procesar, almacenar y distribuir
información para una organización.
UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado
en una notación gráfica, que permite: especificar, construir, visualizar y documentar los
elementos de un sistema software, así como para modelar los procesos de negocios u otros
sistemas no software.
90 Sistema a Distancia
90
Análisis de Sistemas - Unidad V César Luza Montero
BIBLIOGRAFIA
1 Davenport, Thomas (1996). Innovación de Procesos: Reingeniería del trabajo a través de la
tecnología de la información. España. Díaz Santos.
2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for
Business Revolution. USA. Collins Business Essentials.
3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA.
Editorial Harris Training & Consulting Services Inc.
4 IEEE (1990), IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering
Terminology –Description.
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html.
5 Jacobson, I., Booch, G. y Rumbaugh, J. (2000), El Proceso Unificado de Desarrollo de Software.
Madrid. Pearson Educación S.A.
6 Jacobson, I., Booch, G. y Rumbaugh, J. (2006), El Lenguaje Unificado de Modelado UML.
Segunda edición. Madrid. Pearson Educación S.A.
7 Larman, C. (1999). UML y patrones: introducción al análisis y diseño orientado a objetos.
Mexico D.F. Prentice-Hall Hispanoamericana.
8 Larman, C. (2002). UML y patrones: introducción al análisis y diseño orientado a objetos.
Segunda Edición. Madrid. Pearson Educación S.A.
9 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Información Gerencial. 8ª Ed. México
D.F. Pearson Educación.
10 Laudon, Jane y Kenneth (2006). Sistemas de información gerencial, Administración de la
empresa digital. México D.F. Pearson Educación- Prentice Hall.
11 Pressman , Roger S. (2002) Ingeniería de Software. Un enfoque práctico. 5ta.Ed. Mc Graw Hill,
España.
12 Rumbaugh, J. et. al. (1996). Modelado y diseño orientados a objetos. Metodología OMT.
Mexico D.F. Prentice Hall Hispanoamericana.
13 Sommerville, Ian (2005), Ingeniería de Software. Sétima edición. Mexico D.F. Editorial
Pearson.
91 Sistema a Distancia
91