Académique Documents
Professionnel Documents
Culture Documents
Modulo A
Semana 6: Requerimientos……….................……………………………..…...……….53
Bibliografía: ……………………………………………………………………………………………
Contenidos
Esta disciplina trata con áreas muy diversas de la informática y de las ciencias de la
computación, tales como construcción de sistemas operativos, compiladores o desarrollo de
aplicaciones en Intranet / Internet. Aborda todas las fases del ciclo de vida de desarrollo de
cualquier tipo de sistemas de información y es aplicable a una infinidad de áreas tales como:
negocios, investigación científica, medicina, producción, logística, banca y finanzas, derecho,
etc.
Es el marco de trabajo de las tareas, que se requieren para construir software de alta calidad.
Un proceso de software, define el enfoque que se toma cuando el software es tratado por la
ingeniería. La ingeniería de software es una tecnología multicapa como se muestra a
continuación:
HERRAMIENTAS
MÉTODOS
PROCESO
ENFOQUE DE CALIDAD
La fase de definición
La fase de desarrollo
La fase de mantenimiento
La fase de definición
Se centra sobre el qué. El que desarrolla el software intenta identificar qué información ha de
ser procesada, que función y rendimiento se desea, qué comportamiento del sistema, qué inter-
fases van a ser establecidas, qué restricciones de diseño existen y qué criterios de validación
se necesitan para definir un sistema correcto. Por tanto, han de identificarse los requisitos clave
del sistema. Tendrán lugar tres tareas clave:
La fase de mantenimiento
Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones
requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras
producidas por los requisitos cambiantes del cliente. Durante la fase de mantenimiento se
encuentran cuatro tipos de cambios:
- Corrección
- Adaptación
- Mejora
- Prevención
Para resolver los problemas reales de una industria, se debe incorporar una estrategia de
desarrollo, que acompañe al proceso, a los métodos, las herramientas y las fases genéricas
tratadas en los puntos anteriores. Esta estrategia a menudo se llama Modelo de Proceso o
Paradigma de Ingeniería del Software. Se seleccionará un modelo de proceso para la
ingeniería del software según la naturaleza del proyecto y de la aplicación.
MODELO LINEAL
MODELO INCREMENTAL
A D C P Entregable o Incremental 1
A D C P Entregable o Incremental 2
A D C P Entregable o Incremental 3
Es una estrategia de desarrollo que, resuelve problemas reales de la industria del software,
explicando como hay que obtener los distintos productos. La Metodología de desarrollo de
software puede seguir uno o varios modelos de proceso de software. Las metodologías se
clasifican en:
Convencionales
Estructurales
Orientadas a Objetos
Ágiles.
- Booch—OOD.
- Rumbaugh — OMT.
- Catalysis.
- CBDIe.
- Objectory Process 3.8, 4.0,4.1.
- Proceso Unificado 1999.
- Rational Unified Process 5.1, 5.1.1.
Metodologías ágiles
Las metodologías ágiles forman parte del movimiento de desarrollo ágil de software. Se basan
en la adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de éxito
de un proyecto.
• Los individuos y. sus interacciones son más importantes que los procesos y las
herramientas.
• El software que funciona es más importante que la documentación exhaustiva.
• La colaboración con el cliente en lugar de la negociación de contratos.
• La respuesta delante del cambio en lugar de seguir un plan cerrado.
• Se puede decir que, este movimiento empezó a existir a partir de febrero de 2001, cuando
se reunieron los representantes de cada una de estas metodologías y terminaron poniendo
en común sus ideas en una declaración conjunta.
Este proceso de trabajo genérico puede ser especializado para diversos tipos de software de
sistemas, diversas áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles
de competencia y diferentes tamaños de proyectos. Existen tres elementos centrales que
definen a RUP y estos son:
a) El conjunto de filosofías y prácticas que son la base para un desarrollo de software exitoso.
Procesos Esenciales
Topics
1. Vision—Develop a Vision
2. Plan—Manage to the Plan
3. Risks—Mitigate Risks and Track Related Issues
4. Business Case—Examine the Business Case
5. Architecture—Design a Component Architecture
6. Prototype—Incrementally Build and Test the Product
7. Evaluation—Regularly Assess Results
8. Change Requests—Manage and Control Changes
9. User Support—Deploy a Usable Product
10. Process—Adopt a Process that Fits Your Project
Ambos definen el proceso de ingeniería de software base de RUP. Además, permiten al equipo
responsable de desarrollo crear sus propias configuraciones y convertirlo en una metodología
ágil silo desea.
RUP y su estructura
El proceso se describe en dos dimensiones o dos ejes:
El eje horizontal representa tiempo y muestra el aspecto dinámico del proceso, expresado en
términos de ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto estático del proceso como está descrito en términos de
actividades, artefactos, trabajadores y flujos de trabajo.
También, conocidos como disciplinas o flujos de trabajo del proceso. Un workflow de RUP es
una secuencia de actividades que producen un resultado de valor observable.
Iteraciones
Algunas de las metodologías orientadas a objetos que llegaron a ser populares a comienzos de
los 90‘s son:
- Booch: La metodología de Grady Booch para el desarrollo orientado a objetos está disponible
en un sin número de versiones. Booch definió la noción de que un sistema es analizado como
un conjunto de vistas, en el que cada una es descrita por un determinado número de
diagramas de modelo.
- Fusion: Esta metodología proviene de Hewlett—Packard (D. Coleman, 1994). Se conoce con
el nombre de metodología de segunda generación, ya que esta basada en las experiencias de
muchas de las metodologías iniciales. Fusion ha mejorado muchas de las ideas previas e
incluye las técnicas para la especificación de operaciones y la interacción entre objetos. La
metodología tiene un gran número de diagramas de modelos.
Cada una de estas metodologías tenían sus propias notaciones (los símbolos usados para
dibujar los modelos orientado a objetos), procesos (qué actividades realizar en las distintas
etapas de desarrollo), y herramientas (las herramientas CASE que soporten la flotación y
proceso). Esto hace que la elección de una metodología sea una decisión bastante importante,
y frecuentemente lleva a discusiones acaloradas y debates sobre qué metodología es la
―mejor‖, ―más avanzada‖, y la ―correcta‖ para utilizarse en un proyecto específico. Y, con este
HISTORIA DE UML
Unificada‖, la cual une las metodologías Booch y OMT-2 del cual Rumbaugh fue el
desarrollador principal. En 1995, lvar Jacobson, el hombre detrás de las metodologías OOSE y
Objectory, se les unió. Rational Software también compró
Objetive Systems, la compañía sueca que desarrolló y
distribuyó Objectory. En este punto, los futuros
desarrolladores de UML también se dieron cuenta de que
su trabajo tenía como objetivo crear un lenguaje de
modelamiento estándar, y renombraron su trabajo como
―El Lenguaje Unificado de Modelamiento‖. Tener éxito en
establecer un lenguaje de modelamiento estándar es una
tarea más simple que hacer las mismas cosas para un
proceso, a partir de que un proceso difiere
substancialmente entre distintas compañías y culturas. Es
incierto si es del todo posible crear un proceso estándar
que pueda ser utilizado por todos.
Aunque las principales partes del UML están basadas en las metodologías de Booch, OMT, y
OOSE, estos diseñadores de metodologías también incluyeron conceptos de otras
metodologías. Por ejemplo, el trabajo de David Harel sobre los diagramas de estado ha sido
adoptado en los diagramas de estado de UML; partes de la notación de la metodología Fusion
para numerar operaciones han sido incluidas en los diagramas de colaboración; el trabajo de
Gamma-Helm-Johnson-Vlissides en patrones y cómo documentarlos ha inspirado la
elaboración de detalles en los diagramas de clases.
ESTANDARIZACIÓN OMG
Cuando comenzó el trabajo con UML, éste pretendía establecerse por sí mismo como el
estándar de facto, lo cual significa que a través del uso práctico por parte de los
desarrolladores podría ser reconocido como el principal lenguaje de modelamiento. Sin
embargo, cuando OMG requirió un lenguaje de modelamiento UML se dieron cuenta de que
podían hacer de él un una mayor demanda de una definición más formal y estándar, los
desarrolladores de estándar formal. Ello dio lugar a precisa del UML y mejora de la calidad del
lenguaje. Una estandarización formal es importante para muchas de las industrias antes de
aventurarse a usar una nueva tecnología. OMG decidió usar UML como su estándar y está
trabajando en los detalles finales de la especificación. URL: www.omg.org
La sintaxis nos dice cómo deberían lucir los símbolos y cómo se combinan los símbolos en
lenguaje de modelamiento. La sintaxis se compara con las palabras en lenguaje natural; es
importante saber cómo deletrearlas correctamente y cómo juntar distintas palabras para formar
una oración. Las reglas semánticas nos dice qué significa cada símbolo y cómo debería ser
interpretado por sí mismo y, en el contexto de otros símbolos, son comparados con los
significados de las palabras en un lenguaje natural.
Las reglas pragmáticas definen las intenciones de los símbolos a través del cual el propósito de
un modelo es alcanzado y se vuelven entendibles para otros. Esto corresponde en el lenguaje
natural con las reglas de construcción de oraciones las cuales son claras y entendibles. Por
ejemplo, los libros sobre el estilo de escritura se conocen como pragmáticos en dicho sentido.
Para usar bien un lenguaje de modelamiento, es necesario aprender todas estas reglas. La
buena noticia es que UML es mucho más fácil de comprender que un lenguaje natural. La
mayoría de los lenguajes de modelamiento cubre sólo sintaxis y semántica. El pragmatismo es
un poco difícil cuando se trata de describir, ya que no se puede formalizar, tan sólo puede
actuar como guía.
Naturalmente, incluso cuando se domina el lenguaje, no hay garantía de que los modelos
producidos sean buenos. Así como escribir una historia en un lenguaje natural, e lenguaje es
tan solo una herramienta que el autor debe dominar. Más aun depende del autor escribir una
buena historia.
Revisión DE UML
El Lenguaje de Modelamiento Unificado tiene un gran campo de acción. Puede ser usado para
el modelamiento de negocios, modelamiento de software en todas las fases de desarrollo y
para todo tipo de sistemas, y modelamiento general de cualquier tipo de construcción que
tenga tanto una estructura estática como un comportamiento dinámico. Para poder alcanzar
estas capacidades, el lenguaje se define para que sea lo suficientemente extenso y genérico
para permitir el modelamiento de tanta diversidad de sistemas, evitando la extrema
especialización y complejidad.
Diagramas: Los diagramas son los gráficos que describen los contenidos en una vista. UML
tiene nueve tipos de diagramas distintos que se usan en combinación para proveer todas las
vistas del sistema.
Elementos de modelo: Los conceptos usados en los diagramas son elementos de modelo que
representan conceptos orientado a objetos comunes tales como clases, objetos, y mensajes, y
las relaciones entre estos conceptos los cuales incluyen los términos de asociación,
dependencia, y generalización. Un elemento del modelo se usa en varios diagramas diferentes,
pero siempre tiene el mismo significado y símbolo.
Por lo tanto, un sistema se describe en una serie de vistas, en las que cada una representa una
proyección de la descripción del sistema completo y muestra un aspecto en particular del
sistema.
Cada vista se describe con una serie de diagramas que contienen información que enfatizan un
aspecto en particular del sistema. En parte hay cierta concurrencia, de tal forma que un
diagrama puede realmente ser parte de más de una vista. Observando el sistema desde
diferentes vistas, es posible concentrarse en un aspecto del sistema a la vez. Un diagrama en
una vista en particular debería ser lo suficientemente simple para ser fácilmente comunicado,
más aún que sea coherente con los otros diagramas y vistas, de tal forma que la figura
completa del sistema sea descrita por todas las vistas juntas (a través de sus respectivos
diagramas).
Vista de Casos de Uso: Una vista que muestra la funcionalidad del sistema percibida por
actores externos.
Vista Lógica: Una vista que muestra cómo la funcionalidad es diseñada dentro del sistema en
términos de la estructura estática del sistema y comportamiento dinámico.
Vista de Despliegue o Implantación: Una vista que muestra la implementación del sistema
como una estructura física con computadoras y dispositivos llamados nodos. Cuando se
escoge una herramienta para dibujar los diagramas, hay que asegurarse de que sea fácil la
navegación entre una vista y otra. Además, para poder ver como una función es diseñada para
funcionar dentro de un diagrama, la herramienta debería hacer fácil el cambiar ya sea a la vista
de casos de uso, para ver como la función es descrita por un usuario externo o a la vista de
despliegue para ver como la función es distribuida en la estructura física.
Vista de Componentes
La vista de componentes es una descripción de los módulos de implementación y sus
dependencias. Es principalmente para los desarrolladores. Los componentes son diferentes
tipos de módulos de código fuente, binario o ejecutable. Estos se muestran con sus respectivas
estructuras y dependencias. Información adicional acerca de los componentes, tales como
asignación de recursos (responsabilidad para un componente), u otra información
administrativa, como un reporte de progreso para el trabajo de desarrollo, también pueden ser
incluidos.
Vista de Despliegue
Muestra el despliegue físico del sistema, tales como computadoras y dispositivos (nodos) y
como se conectan entre ellos. La vista de despliegue es para los desarrolladores, integradores,
y evaluadores. Se representa con el diagrama de despliegue. Esta vista también incluye una
relación que muestra cómo los componentes son implementados en la arquitectura física; por
ejemplo, qué objetos se ejecutan en sus respectivas computadoras.
A continuación, se describirán los conceptos básicos detrás de cada diagrama. Todos los
detalles referentes a los diagramas, su sintaxis, su significado exacto y cómo interactúan se
describirán a lo largo de los capítulos del curso.
Diagrama de Clases
Un diagrama de clases muestra la estructura estática de las clases en el sistema. Las clases
representan las ―cosas‖ que son manipuladas en el sistema. Las clases pueden estar
relacionadas entre ellas en distintas formas: asociada (conectada entre ellas), dependiente
(una clase depende / usa otra clase), especializada (una clase es una especialización de otra
clase) o empaquetada (agrupada como una unidad). Todas estas relaciones se muestran en un
diagrama de clases junto con la estructura interna de las clases en términos de atributos y
operaciones. El diagrama es considerado estático cuando la estructura descrita es siempre
válida en cualquier punto del ciclo de vida del sistema.
Los diagramas de objetos no son tan importantes como los diagramas de clases, pero pueden
ser utilizados para ejemplificar un diagrama de clases complejo mostrando como las instancias
reales y las relaciones se verían. Los diagramas de objetos también se usan como parte de los
diagramas de colaboración, en la que la colaboración dinámica entre un conjunto de objetos se
muestra.
Diagrama de Estados
Un diagrama de estados es típicamente un complemento de la descripción de una clase.
Muestra todos los posibles estados que los objetos de una clase pueden tener, y qué eventos
provocan el cambio de estado. Un evento puede ser otro objeto que le envía un mensaje, por
ejemplo, que un determinado tiempo ha transcurrido, o que alguna condición se ha cumplido.
Un cambio de estado se llama transición. Una transición también puede tener una acción
asociada a ella que específica qué se debería hacer con relación a la transición de estado.
Los diagramas de estado no se hacen para todas las clases, es sólo para aquellas que tengan
un número de estados bien definidos y en donde el comportamiento de la clase es afectado y
cambiado por los distintos estados. Los diagramas de estado también pueden ser hechos para
todo el sistema en su totalidad.
Diagramas de Colaboración
Un diagrama de colaboración muestra una colaboración dinámica, así como lo hace un
diagrama de secuencia. Frecuentemente queda a criterio del usuario mostrar la colaboración
ya sea en un diagrama de secuencias o como un diagrama de colaboración. Además de
mostrar el intercambio de mensajes (interacción), el diagrama de colaboración muestra a los
objetos y sus relaciones (algunas veces referidas como el contexto). Ya sea que use un
diagrama de secuencias o un diagrama de colaboración, frecuentemente, se puede decidir por
lo siguiente: Si el aspecto más importante de enfatizar es el tiempo o secuencia, escoja el
diagrama de secuencias; en cambio, si importa enfatizar el contexto, escoja el diagrama de
colaboración. La interacción entre los objetos se muestra en ambos diagramas.
Diagrama de Despliegue
El diagrama de despliegue muestra la arquitectura física de hardware y software en el sistema.
Puede mostrar las computadoras y dispositivos reales (nodos) junto con las conexiones que
presentan entre ellos; también, puede mostrar el tipo de conexiones. Dentro de los nodos, los
componentes ejecutables y objetos son ubicados con el fin de mostrar qué unidades de
software se ejecutan en determinados nodos. También puede mostrar las dependencias entre
los componentes.
Contenidos
Un modelo de caso de uso consta de un número de elementos del modelo. Los elementos del
modelo más importantes son: casos de uso, actores y las relaciones entre estos.
Un diagrama de caso de uso es usado para mostrar gráficamente un subconjunto del modelo
para simplificar las comunicaciones. Típicamente tendrá varios diagramas de caso de uso
asociados a un modelo dado, cada uno mostrando un subconjunto de los elementos del
modelo relevantes para un propósito particular. El mismo elemento del modelo podría ser
mostrado en varios diagramas de caso de uso, pero cada instancia debe ser consistente. Si se
usan herramientas para administrar el modelo de caso de uso, esta restricción de consistencia
es automatizada tal que cualquier cambio a los elementos del modelo (por ejemplo cambiar el
nombre) será automáticamente reflejado en cada uno de los diagramas de caso de uso que
muestran este elemento.
El modelo de caso de uso podría contener paquetes que son usados para estructurar el
modelo, simplificar el análisis, las comunicaciones, la navegación, el despliegue, el
mantenimiento y la planeación.
Muchos de estos modelos de caso de uso son hechos en texto, con el texto capturado en la
Use-Case Specifications que son asociadas con cada elemento del modelo de casos de uso.
Estas especificaciones describen el flujo de eventos del caso de uso.
El modelo de caso de uso sirve como un hilo unifcador entre los desarrolladores del sistema.
Es usado como la primera especificación de los requisitos funcionales para el sistema, como la
base para el análisis y diseño, como una entrada para planear la iteración, como las bases
para definir los casos de prueba y como las bases para la documentación del usuario.
Actor
Un elemento del modelo para representar cada actor. Las propiedades incluyen los nombres de
los actores y una breve descripción.
Asociaciones
Las asociaciones son usadas para describir las relaciones entre actores y los casos de uso en
los que ellos participan. Estas relaciones son conocidas comúnmente como una "asociación
comunicante".
Modelo de Negocio.
La disciplina Modelamiento del Negocio describe la organización actual y desarrolla la visión de
una nueva. Utilizando esta visión como base, define los procesos, roles y responsabilidades de
la organización en dos partes: un modelo de casos de uso de negocio y un modelo de análisis
de negocio.
Proyecto de Sistema
Análisis Estratégico
Versión 1.5
Contenido
1. Información del Negocio ........................................................................................................... 34
2 Estrategias: ................................................................................................................................ 34
3 Organización:............................................................................................................................. 36
Modelo de Negocio ...........................................................................................................................
1. Descripción del Negocio: ........................................................................................................... 39
2. Objetivos de Negocio: ............................................................................................................... 40
3. Casos de Uso de Negocio: ......................................................................................................... 41
4. Actores de Negocios: ................................................................................................................. 41
Modelo de Análisis ........................................................................... ¡Error! Marcador no definido.
1. Entidades de Negocio ................................................................................................................ 47
2. Realizaciones de Caso de Uso ................................................................................................... 48
3. Trabajadores de Negocio ............................................................. ¡Error! Marcador no definido.
Modelo de Casos de Uso .................................................................. ¡Error! Marcador no definido.
1. Casos de Uso ............................................................................................................................. 67
2. Especificaciones de Casos de Uso ............................................................................................. 69
Modelo de Conceptual ..................................................................... ¡Error! Marcador no definido.
1. Diagrama de Clases .......................................................................................................................
2. Diagramas de Estado .....................................................................................................................
3. Diagrama de Colaboración ...................................................................................................... 111
4. Diagrama de Secuencia .................................................................................................................
1.1 Nombre:
Nombre comercial: PECSA (ChevronLubricants)
Razón Social: Peruana De Estaciones S.A.C.
1.2 Giro:
Venta de Combustibles
1.3 Dirección:
Av. Tomás Marzano 4070 - Surco
1.4 Teléfono:
4482770
1.5 StakeHolder:
Patrick Meza Ortega
2. Estrategias:
2.1 Visión del Negocio:
Es una empresa integrada anticipada al futuro y a la competencia
en permanente exploración de nuevas oportunidades,
explotándolas en armonía con el medio ambiente, las
necesidades de nuestros clientes, la satisfacción de nuestros
consumidores, las expectativas de nuestro personal y de nuestros
accionistas.
2.3.2 Tácticos:
Los objetivos del proceso de abastecimiento son
los siguientes:
Generar correctamente las mediciones de
la cantidad de producto que se almacena
en los tanques de combustible líquido y
gaseoso.
Generar armoniosamente los
requerimientos de producto para
satisfacer la demanda de los
consumidores.
Constatar el correcto abastecimiento de
los productos en las diferentes válvulas de
llenado de los tanques, y corroborar la
cantidad de producto suministrado,
obedeciendo los protocolos de seguridad
establecidos para este proceso.
Administrador
Coordinador Administrativo
Coordinador Operativo
Proyecto De Sistema
Modelo de Negocio
Versión 1.0
Abastecimiento de Combustible
4. Actores de Negocios:
LVM Inversiones
PGN - Cálida
Contenidos
El propósito del modelo del análisis de negocio es describir cómo se ejecutan los casos del uso
del negocio.
Trabajador de Negocio.-
Un trabajador del negocio o Business Worker es una abstracción de un sistema, de un ser
humano o de un software que represente un rol realizado dentro de realizaciones del caso del
uso del negocio.
Un trabajador del negocio colabora con otros trabajadores del negocio, se notifica de
acontecimientos del negocio y manipula entidades de negocio para realizar sus
responsabilidades.
Entidad de Negocio.-
Representa un pedazo de la información significativo y persistente que es manipulada por los
agentes del negocio y los trabajadores del negocio.
Proporcionan la base para compartir información (documentos) entre los trabajadores del
negocio que participan en diversas realizaciones del caso del uso del negocio.
Representan una abstracción de la información persistente importante dentro del negocio. Por
ejemplo, el inventario del producto es ciertamente información significativa, pero ésta no es
información persistente.
Realización de CUN.-
Describe cómo los trabajadores de negocio y las entidades de negocio colaboran para realizar
un caso de uso de negocio particular.
Mientra que un caso de uso de negocio describe qué pasos se debe realizar para entregar
valor a un stakeholder del negocio, una realización del CUN describe cómo estos pasos se
realizan dentro de la organización.
Los CUN se describen de una perspectiva externa, mientras que la realización de casos de uso
del negocio, se describe de una perspectiva interna.
Proyecto De Sistema
Modelo de Análisis de Negocio
Versión 1.0
EN_Factura
EN_Guia de remision
EN_Historial de medición
EN_Inventario de medicion
EN_Reporte de ventas
EN_Lista de requerimientos
EN_Guia de conversion
RCUN_Captura de
requerimientos y abstecimiento
TN_Jefe de pista
TN_Coordinador administrativo
TN_Coordinador operativo
TN_Administrador
TN_Representante de servicio
Contenidos
En esta semana, el instructor revisará los proyectos desarrollado por los alumnos, en el que se
debe crear y aplicar los conceptos estudiados.
Contenidos
- Lección 1: Requerimientos
Los casos de uso proporcionan un medio intuitivo y sistemático para capturar los requisitos
funcionales con un énfasis especial en el valor añadido para cada usuario individual o para
cada sistema externo.
El modelo de casos de uso es construido a través de un proceso iterativo durante el cual las
discusiones entre los desarrolladores del sistema y los clientes (y/o usuarios finales) llevan a
una especificación de requerimientos en la que todos estén de acuerdo.
- Decidir y describir los requerimientos funcionales del sistema, que resultan en un acuerdo
entre el cliente (yo el usuario final) y los desarrolladores de software que están construyendo el
sistema.
- Dar una descripción consistente y clara de lo que debería hacer el sistema, de la forma que el
modelo sea usado a lo largo de todo el proceso de desarrollo cara comunicar a todos los
desarrolladores dichos requerimientos, y proveer las bases para futuros modelamientos de
diseño que provean la funcionalidad requerida.
- Dar una base para ejecutar pruebas de desempeño del sistema que verifique e. sistema. Por
ejemplo, preguntándose, ¿el sistema final realmente ejecuta la funcionalidad inicialmente
requerida?
- Proveer la habilidad de trazar los requerimientos funcionales hacia las clases y operaciones
reales en el sistema.
El trabajo real requerido para crear modelos de casos de uso envuelve definir el sistema,
encontrar los actores y los casos de uso, describir los casos de uso, definir las relaciones entre
los casos de uso y finalmente validar el modelo. Es un formato altamente interactivo que
deberían incluir discusiones con el cliente y la gente que representa a los actores. Los modelos
visuales no pueden proveer toda la información necesaria en un modelo de casos de uso, por
ello se emplean tanto los diagramas de casos de uso y descripciones textuales.
El cliente y/o usuario final está interesado en ellos ya que los modelos de casos de uso
especifican la funcionalidad del sistema y describen como el sistema puede y será utilizado. Es
realmente útil cuando el usuario presenta un rol activo en el modelamiento de casos de uso ya
que los modelos pueden ser adaptados al detalle a los deseos del cliente. Los casos de uso se
describen en lenguaje y terminología del usuario final.
Los desarrolladores necesitan los modelos de casos de uso para entender qué debería hacer el
sistema y proveerles de las bases para futuros trabajos (otros modelos, diseño de la
arquitectura, e implementación).
El modelo de casos de uso representa la vista de casos de uso del sistema. Esta vista es bien
importante, ya que afecta a todas las vistas del sistema. Tanto la arquitectura física y lógica se
ven influenciadas por los casos de uso, debido a que las funciones especificadas en el modelo
de casos de uso son implementadas en dichas arquitecturas. Una solución es diseñada para
satisfacer estos requerimientos.
Actores
Casos de uso
Modelo de casos de uso
El actor es cualquier entidad externa que tiene un interés en interactuar con el sistema.
Frecuentemente, es un usuario humano del sistema, pero puede ser algún otro sistema o algún
tipo de dispositivo de hardware que necesite interactuar con el sistema.
En el modelo de casos de uso, el sistema es visto como una ―caja negra‖ que provee casos de
uso. Cómo el sistema lo hace, cómo los casos de uso son implementados y cómo trabajan
internamente no es importante. En realidad, cuando el modelo de casos de uso se hace con
anticipación en el proyecto, los desarrolladores no tienen idea de cómo los casos de uso van a
ser implementados.
Actores
Un actor es alguien o algo que interactúa con el sistema. Es algo o alguien que usa el
sistema. Por ‗interactuar con el sistema‖, queremos decir que el actor envía o recibe
mensajes hacia y desde el sistema o intercambia información con el sistema. En pocas
palabras, los actores ejecutan los casos de uso. Nuevamente, un actor puede ser un ser
humano o algún otro sistema (como otra computadora en la cual el sistema es conectado o
algún tipo de dispositivo de hardware que se comunica con el sistema).
Un actor es un tipo (una clase), no una instancia. El actor representa un rol, no a un usuario
individual del sistema. Si John Doe desea un seguro de automóviles de una compañía de
seguros, su rol es de un comprador de seguros o asegurado, que deseamos modelar, más
no John Doe. En realidad, una misma persona podría poseer diferentes actores en el
sistema, dependiendo de su rol en él. Y los roles que una persona podría tener en el
sistema pueden ser restringidos. Por ejemplo, la misma persona puede estar prohibida de
generar y aprobar una factura. Un actor tiene un nombre, y el nombre debería reflejar el rol
del actor. El actor se comunica con el sistema enviando y recibiendo mensajes, los cuales
son similares a aquellos encontrados en la programación orientada a objetos, aunque no
son como los especificados formalmente en un caso de uso. Un caso de uso siempre es
iniciado por un actor al enviarle un mensaje. Algunas veces se le da el nombre de estímulo.
Cuando un caso de uso es ejecutado, el caso de uso podría enviar mensajes a uno o más
actores. Estos mensajes podrían ir también a otros actores a parte de aquel que inició el
caso de uso.
Los actores pueden ser calificados. Un actor principal es aquel que utiliza las funciones
principales del sistema, como la función principal. Por ejemplo, en un sistema de seguros,
un actor principal podría ser aquel que se encarga de manejar el registro y administración
del seguro. Un actor secundario es aquel que utiliza las funciones secundarias del sistema,
aquellas funciones que mantienen el sistema, como la administración de bases de datos,
comunicaciones, backups, y otras tareas de administración. Un ejemplo de actor
secundario podría ser un administrador o algún otro miembro que utilice las funciones en el
sistema para recuperar estadísticas sobre el negocio de la compañía. Ambos tipos de
actores se modelan para asegurar que la funcionalidad completa del sistema sea descrita,
incluso cuando las funciones principales sean aquellas que interesen más al cliente.
Los actores también se pueden definir como activos y pasivos. Un actor activo es aquel
que inicializa un caso de uso, mientras que un actor pasivo nunca inicializa un caso de uso,
pero solo participa en uno o más casos de uso.
- ¿Quién necesitará apoyo del sistema para hacer sus tareas diarias?
- ¿Con qué otros sistemas necesita interactuar el sistema? Esto se puede dividir en
sistemas que inician el contacto con el sistema y los sistemas que el sistema contactará.
Los sistemas incluyen otros sistemas informáticos así como también otras aplicaciones en
la computadora en la que residirá el sistema.
- ¿Quién o qué tiene interés en los resultados (el valor) que el sistema produce?
Cuando se busca a los usuarios del sistema, no sólo considere a quienes se sentarán
frente a la pantalla de la computadora. Recuerde, el usuario puede ser cualquiera o
cualquier cosa que directa o indirectamente interactúe con el sistema y utilice los servicios
del sistema para alcanzar algo. Tenga presente que el modelamiento de casos de uso se
hace para modelar un sistema; por lo tanto los actores usualmente son los clientes de
dicho negocio. En ese sentido no sólo son usuarios de computadoras.
Una manera de encontrar diferentes actores es llevar a cabo un estudio de los usuarios del
sistema actual (un manual del sistema o un sistema existente) y preguntar cuáles son los
distintos roles que desempeñan cuando realizan su trabajo diario con el sistema. El mismo
usuario podría interpretarse en distintos roles en diferentes oportunidades, dependiendo de
qué funciones en el sistema estén actualmente en uso.
Repitiendo, un actor es un rol (una clase), no una instancia individual. Sin embargo, dando
ejemplos de un par de instancias de un actor, se puede validar si realmente el actor existe.
Un actor debe tener alguna asociación con uno o más casos de uso. Aunque el actor no
podría iniciar un caso de uso, el actor en algún punto del tiempo se comunicará con uno. El
actor recibe un nombre que refleje su rol en el sistema.
Actores en UML
Tenga presente que los actores en UML son clases con el estereotipo de «actor», y que el
nombre de la clase es el nombre del actor (reflejando el nombre del actor), una clase actor
puede tener tantos atributos como compartimientos así como también una propiedad de
documentación que describe al actor. Una clase actor tiene un icono de estereotipo
estándar.
Si se tiene presente que los actores son clases, pueden tener las mismas relaciones que
presenta una clase. En los diagramas de casos de uso, sólo las relaciones de
generalización se emplean para describir el comportamiento común entre un determinado
número de actores.
Generalización
Cuando existen varios actores o roles que desempeñan un rol más generalizado, esto se
describe como una generalización. Esto ocurre cuando el comportamiento del rol en
general se describe como actor padre. Los actores especializados heredan el
comportamiento del actor padre, extendiéndose el comportamiento. La generalización entre
actores se muestra con una línea con un triangulo vacío en el extremo de la superclase
más general. Esta es la misma notación empleada para la generalización entre cualquiera
de las clases en UML.
Un caso de uso representa una funcionalidad completa como es percibida por un actor. Un
caso de uso en UML se define como una secuencias de acciones que un sistema ejecuta,
el cual arroja un resultado observable para un actor en particular. Las acciones pueden
involucrar la comunicación con un determinado número de actores (usuarios y otros
sistemas) así como también realizar cálculos y trabajos dentro del sistema. Las
características de un caso de uso son:
- Un caso de uso la mayor parte de veces es siempre iniciado por un actor. Un caso de uso
es siempre ejecutado en nombre del actor. El actor debe directa o indirectamente ordenar
al sistema que se ejecute el caso de uso.
- Un caso de uso provee valor para aun actor: Un caso de uso debe entregar algún tipo de
valor tangible para el usuario.
- Un caso de uso es completo: Un caso de uso debe ser una descripción completa. Un
error común es dividir un caso de uso en casos de usos más pequeños que luego implican
llamar a más funciones en un lenguaje de programación. Un caso de uso no está completo
hasta que el valor final se produzca.
Los casos de uso se conectan con los usuarios a través de asociaciones, los cuales
algunas veces son referidos como asociaciones de comunicación. Las asociaciones
muestran con qué actores se comunican los casos de uso, incluyendo al actor que inicializa
la ejecución del caso de uso. La asociación es normalmente una relación de uno-a-uno sin
dirección. Esto significa que una instancia de actor se comunica con una instancia de caso
de uso, y que ambos se pueden comunicar en ambas direcciones. Un caso de uso recibe el
nombre acorde al caso de uso que ejecute, como Registro de Actualización, y es
frecuentemente una frase en vez de una etiqueta con una sola palabra.
El proceso para encontrar casos de uso empieza con el actor previamente definido. Para
cada uno de los actores identificados, pregúntese lo siguiente:
- ¿Qué funciones requiere el actor del sistema? ¿Qué necesita hacer el usuario?
- ¿Necesita el usuario leer, crear, destruir, modificar, o almacenar algún tipo de información
en el sistema?
- ¿Necesita el actor ser notificado sobre algún evento en el sistema, o el actor necesita
notificar algo al sistema? ¿Qué representan estos eventos en términos de funcionalidad?
- ¿Podría el trabajo diario del actor ser simplificado o ser más eficiente a través de nuevas
funciones en el sistema (típicamente funciones que actualmente no estén automatizadas
en el sistema)?
Un caso de uso se representa en UML como una elipse, la cual contiene el nombre del
caso de uso o lleva el nombre del caso de uso debajo de él. Un caso de uso es
normalmente ubicado dentro de los límites del sistema y puede ser conectado al actor
como una asociación o como una asociación de comunicación que muestra como el caso
de uso y el actor interactúan.
Existen tres tipos de relaciones entre casos de uso: extend, include y generalización.
Relación extend: Una relación donde un caso de uso se deriva de otro caso de uso
agregando acciones a un caso de uso general. El caso de uso extendido podría incluir el
comportamiento a partir del caso de uso de donde se extiende llamado caso de uso base
dependiendo de las condiciones de la extensión.
Relación include: Una relación donde un caso de uso emplea otro caso de uso, indica que
al ser parte del caso de uso base, el comportamiento del caso de uso incluido también se
llevará a cabo.
Relación Extend .- Se utiliza para demostrar que una parte del caso de uso es
opcional, de esta manera se separa el comportamiento opcional del
comportamiento obligatorio en su modelo. También se le conoce como
comportamiento añadido.
Para demostrar que un subflujo es ejecutado sólo bajo ciertas condiciones como un
trigger o alarma. Los segmentos de comportamiento que son insertados como
puntos de extensión en el caso de uso base, dependerán de la interacción con los
actores durante la ejecución del caso de uso base. La extensión es condicional, lo
que quiere decir que su ejecución es dependiente de lo que suceda mientras se
ejecuta el caso de uso base. Para llegar al caso de uso extendido el único camino
es a través del caso de uso base. Una relación extend entre casos de uso se
Objetivos para el caso de uso: ¿Cuáles son los objetivos principales para este caso de
uso? ¿Qué está tratando de alcanzar? Los casos de uso son orientados a objetivos.
¿Cómo el caso de uso es iniciado?: ¿Qué actor inicia la ejecución del caso de uso, y en
qué situaciones?
El flujo de mensajes entre os actores y los casos de uso: ¿Qué mensajes o eventos el caso
de uso y el actor intercambian para notificarse el uno a otro. actualizarse o recuperar
información, y apoyarse entre ellos con decisiones? ¿Qué debería describir el flujo principal
de mensajes entre el sistema y los actores, y qué entidades en el sistema son empleadas o
modificadas?
Flujo alterno en el caso de uso: Un caso de uso puede tener ejecuciones alternas
dependiendo de las condiciones o excepciones. Menciónelas, pero tenga cuidado de no
describirlas con mucho detalle ya que podrían ―ocultar‖ el flujo principal de las acciones en
el caso general. El manejo específico de errores se describen como escenarios.
¿Cómo el caso de uso termina dándole un valor al actor?. Se da cuando el caso de uso se
considera como terminado y el valor es entregado al actor.
Recuerde que la descripción identifica lo que se haga como importante para el usuario
externo, no cómo las cosas se hacen dentro del sistema. El texto debería ser claro y
consistente de tal forma que el usuario pueda entenderlo y validarlo (aceptar que
representa lo que desea del sistema). Evite oraciones complicadas que son difíciles de
interpretar y fácil de malinterpretar.
Después de describir los casos de uso, una actividad específica revela si las relaciones
previamente definidas son correctas. Mientras no se describan todos los casos de uso los
desarrolladores no tendrán el conocimiento completo para identificar relaciones adecuadas,
de otra manera sería peligroso intentarlo.
Ejemplo:
Proyecto De Sistema
Modelo de Caso de Uso
Versión 1.0
Contenidos
Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los
sistemas, donde se crea el diseño conceptual de la información que se manejará en el
sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y
otro.
Clase
Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una
instancia de una clase). A través de ella podemos modelar el entorno en estudio (una
Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectángulo que posee tres divisiones:
En donde:
Ejemplo:
Atributos:
Los atributos o características de una Clase pueden ser de tres tipos, los que definen el
grado de comunicación y visibilidad de ellos con el entorno, estos son:
public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.
private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus
métodos lo pueden accesar).
protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si
podrá ser accesado por métodos de la clase además de las subclases que se deriven
(ver herencia).
Métodos:
Los métodos u operaciones de una clase son la forma en como ésta interactúa con su
entorno, éstos pueden tener las características:
public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es
decir, es accsesible desde todos lados.
private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden accesar).
protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si
podrá ser accesado por métodos de la clase además de métodos de las subclases que
se deriven (ver herencia).
Herencia (Especialización/Generalización):
Indica que una subclase hereda los métodos y atributos especificados por una Super
Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá
las características y atributos visibles de la Super Clase (public y protected), ejemplo:
Agregación:
Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los
lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer
objetos que son instancias de clases definidas por el desarrollador de la aplicación,
tenemos dos posibilidades:
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido
esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es
comunmente llamada Composición (el Objeto base se construye a partir del objeto
incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relación es comunmente
llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).
Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee
las referencias).
Asociación:
La relación entre clases conocida como Asociación, permite asociar objetos que colaboran
entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un
objeto no depende del otro.
Ejemplo:
Representa un tipo de relación muy particular, en la que una clase es instanciada (su
instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso más particular de este tipo de relación es para denotar la dependencia que tiene una
clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la
creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el
objeto Aplicación):
Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se
almacena dentro del objeto que lo crea (en este caso la Aplicación).
Casos Particulares:
Clase Abstracta:
Una clase abstracta se denota con el nombre de la clase y de los métodos con
letra "itálica". Esto indica que la clase definida no puede ser instanciada pues
posee métodos abstractos (aún no han sido definidos, es decir, sin
implementación). La única forma de utilizarla es definiendo subclases, que
implementan los métodos abstractos definidos.
Clase parametrizada:
Contenidos
En esta sesión se trabajará con las clases persistentes y se resaltará la diferencia entre el
modelamiento de una base de datos tradicional y el diseño de una base de datos con UML.
Mientras que el modelamiento de base de datos sólo enfoca la descripción de la base de datos,
el diseño de las base de datos con UML avanza a lo largo de todo el proceso de construcción
de software, es decir, desde el proceso del negocio, captura de requisitos, análisis, diseño,
construcción hasta la implantación y pruebas.
Para llevar a cabo este diseño, se identificarán las clases persistentes a partir de las
especificaciones de los casos de uso y las entidades de negocio. Finalmente, todas las clases
las integraremos en un modelo conceptual.
MODELO CONCEPTUAL
La identificación de conceptos forma parte de una investigación del dominio del problema. El
lenguaje UML contiene la flotación en diagramas de estructura estática que explican
gráficamente los modelos conceptuales.
Puede mostrarnos:
Conceptos
Conceptos entre conceptos
Atributos de conceptos.
Los artefactos del software, como una ventana o una base de datos
Las responsabilidades o métodos.
Conceptos
En términos informales el concepto es una idea, cosa u objeto. En un lenguaje más formal,
podemos considerarlo a partir de su símbolo, intención y extensión:
Se considera, por ejemplo, el concepto del evento de una transacción de compra. Podemos
optar por designarlo con el símbolo Venta. La intención de una Venta puede afirmar que
‗representa el evento de una transacción de compra y tiene fecha y hora‖. La extensión de
Venta son todos los ejemplos de venta; en otras palabras, el conjunto de todas las ventas.
Los problemas del software a veces son complejos. La descomposición — divide y vencerás-
es una estrategia que suele utilizarse para resolver la complejidad porque divide el espacio del
problema en unidades comprensibles. En el análisis estructurado, la dimensión de la
descomposición se realiza mediante procesos o funciones. En cambio, en el análisis orientado
a objetos, se lleva a cabo, fundamentalmente con conceptos.
Por tanto, una tarea primordial de la fase de análisis consiste en identificar varios conceptos en
el dominio del problema y documentar los resultados en un modelo conceptual.
Por ejemplo, en el dominio del problema real de comprar productos en una tienda o en una
terminal de punto de venta (TPDV) intervienen los conceptos de Tienda. TPDV y una Venta.
Por lo tanto, el modelo conceptual puede incluir una Tienda, TPDV y una Venta.
Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que
no especificarlo cabalmente
Es frecuente omitir conceptos durante la fase inicial de identificación y descubrirlos más tarde
cuando se examinen los atributos o asociaciones o durante la fase de diseño. Cuando se
detecten, habrá que incorporarlos al modelo conceptual.
Otra técnica muy útil (por su simplicidad) consiste en identificar las frases nominales en las
descripciones textuales del dominio de un problema y considerarlas conceptos o atributos
idóneos.
Este método hay que utilizarlo con mucha prudencia. No es posible encontrar mecánicamente
correspondencias entre sustantivo y concepto, y además las palabras del lenguaje natural son
ambiguas.
Pese a ello, esta técnica es fuente de inspiración. Las especificaciones de los casos de uso son
un excelente punto de partida para identificar las frases nominales Por ejemplo, puede usarse
el caso de uso Comprar Productos.
1. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV con productos que
desea comprar.
2. El Cajero registra el código universal de productos (CUP) en cada producto. Si hay más de
un producto, el Cajero puede introducir también la cantidad.
Algunas de las frases nominales anteriores son conceptos idóneos, algunas pueden ser
atributos de conceptos.
Una debilidad de este enfoque es la precisión del lenguaje natural; varias frases nominales
pueden designar el mismo concepto o atributo entre otras ambigüedades que pueden
presentarse. Pese a ello, no dudamos en recomendar usarlo en combinación con el método de
Lista de categoría de conceptos.
TPDV EspecificacióndeProducto
Producto VentasLíneadeProductos
Tienda Cajero
Venta Cliente
Pago Gerente
3. Incorpore las asociaciones necesarias para registrar las relaciones para las cuales debe
reservar un espacio en la memoria (tema que se expondrá en un capítulo posterior).
4. Agregue los atributos necesarios para cumplir con las necesidades de información (tema
que se tratará en un capítulo posterior.
• Los cartógrafos se sirven de nombres del territorio — no cambian los nombres de ciudades en
sus mapas. En el caso de un modelo conceptual, ello significa utilizar el vocabulario del
dominio cuando se asignan nombres a los conceptos y a los atributos. Por ejemplo, al
desarrollar el modelo de una biblioteca, al cliente se le designará con los nombres que utilice el
personal: visitante, lector u otro semejante.
• Un cartógrafo elimina cosas en el mapa en caso de que no las juzgue pertinentes para el
propósito que persigue, así no es necesario que muestre la topografía ni las poblaciones. De
modo análogo, un modelo conceptual puede excluir en el dominio del problema los conceptos
que no se relacionen con los requerimientos. Por ejemplo, podemos omitir Pluma o Bolsa de
Papel en nuestro modelo conceptual (con el conjunto actual de requerimientos), por no tener
una función importante que sea obvia.
Tal vez el error más frecuente cuando se crea un modelo conceptual es el de representar algo
como atributo, cuando debió haber sido un concepto. Una regla práctica para no caer en él es:
Por ejemplo, pongamos el caso del dominio de las reservaciones en líneas aéreas.,Debería
Destino ser un atributo de Vuelo o un concepto aparte Aeropuerto?
Antaño, mucho antes del advenimiento de las terminales instaladas en el punto de venta, una
tienda llevaba un registro: un libro donde se asentaba las ventas y los pagos. Con el tiempo,
fue automatizado en un registro mecánico de efectivo. Hoy esa terminal desempeña el papel
del registro.
Un registro es una cosa que asienta las ventas y los pagos, pero también lo es la terminal
instalada en el punto de ventas. No obstante, el término registro parece tener un significado
más abstracto y denota una implementación menos orientada que TPDV. Pues bien, ¿en el
modelo conceptual deberíamos utilizar el símbolo Registro en vez de TPDV?
Conforme al principio del cartógrafo, TPDV es un término usual en el territorio, por lo cual es un
símbolo útil desde el punto de vista del conocimiento y la comunicación. Registro es atractivo y
útil, según la meta de crear modelos que representen abstracciones y que no dependan de la
implementación.
Ambas opciones tienen sus bondades. En este caso de estudio hemos escogido TPDV.
Algunos sistemas de software están destinados a dominios que presentan muy poca
semejanza con los dominios naturales o con los de las empresas. Un ejemplo lo constituye el
software de las telecomunicaciones. Todavía es posible crear un modelo conceptual en esos
dominios, pero se requiere un alto grado de abstracción y abandonar los diseños comunes.
Suponga lo siguiente:
Un Elemento tiene una descripción, precio y código universal de producto, los cuales no están
registrados en ninguna otra parte.
Cada vez que se vende un elemento físico, en ―terreno del software‖ se elimina una instancia
del software correspondiente a Elemento.
Existe gran demanda de una nueva hamburguesa: ObjetoHamburguesa. La tienda vende todas
sus existencias, lo cual significa que todas las instancias de Elemento de ObjetoHamburguesa
se cancelan en la memoria de la computadora.
Ahora bien, ésta es la esencia del problema: si alguien pregunta: ―,Cuánto cuesta el
ObjetoHamburguesa?, nadie podrá contestarle porque la memoria de su precio se anexó a las
instancias inventariadas, que fueron eliminándose conforme se vendían
Nótese, asimismo, que el modelo actual si se implementa en el software tal como se describe,
posee datos duplicados y maneja ineficientemente el espacio, porque la descripción, el precio y
el código universal de producto se duplican en cada instancia de Elemento del mismo producto.
La eliminación de las instancias de las cosas que describen Elemento, por ejemplo, da
por resultado una pérdida de la información que ha de conservarse, debido a (a
asociación incorrecta de la información con lo eliminado.
Reduce información redundante o duplicada
He aquí un último ejemplo Imagine que una compañía aérea sufre al accidente fatal de uno de
sus aviones. Suponga que todos los vuelos quedan cancelados por seis meses, mientras se
lleva a cabo la investigación. Suponga además que. cuando se cancelan los vuelos, sus
correspondientes objetos de software Vuelo se eliminan en la memoria de la computadora. Así,
todos los objetos Vuelo quedan eliminados tras el accidente.
Si el único registro del aeropuerto al cual se dirige un vuelo está en las instancias Vuelo, que
representan vuelos específicos en determinado día y hora, ya no habrá un registro de qué rutas
tiene la línea aérea.
Proyecto De Sistema
Modelo Conceptual
Versión 1.0
CLS_Administrador
recibiendo inventario
de medicion
evaluando inventario
de medicion
generando lista de
requeriminetos
enviando lista de
requerimientos
recibiendo inventario
de medicion
revisando inventario
de medicion
entregando inventario
de medicion
recibiendo historial
de medicion
revisando historial
de medicion
comparando con el
reporte de ventas
generando inventario
de medicion
realizando
medicion diaria
generando historial
de medicion
firmando
consultando guia de factura y guia
conversion
completando formulario
completando historial de descarga segura
de medicion
recibiendo revisando el
factura y guia contenedor del camion
entregando
recibiendo
consultando
firmando
generando
completando
enviando
recibiendo
firmando
CLS_Guia_Conversion
consultando
entregando
recibiendo
consultando
firmando
generando
completando
enviando
recibiendo
generando
revisando
anulando
CLS_Lista_requerimientos
genenerando
enviando
recibiendo
recibiendo lista de
requerimientos
entregando
factura
entregando guia de
remision
abasteciendo
firmando formulario de
descarga segura
CLS_Reporte_ventas
consultando
comparando
Contenidos