Manual ADSIv15

 Presentación…………………………………………………………………………………………..
 Modulo A
 Semana 1: Conceptos generales.......................................…………......……...4
 Semana 2: Casos de Uso......…........................................................................28
 Semana 3: Caso práctico dirigido..................................................…..………28
 Semana 4: Diagramas Complementarios......….............…………........….………42
 Semana 5: Revisión de conocimiento…….........................................…….....52
 Semana 6: Requerimientos……….................……………………………..…...……….53
 Semana 7: Diagramas de clases ………………………………...............…………….79
 Semana 8: Caso Práctico – Aplicación diagrama de clases.…………….………..86
 Semana 9: Repaso de conocimiento……….....................................…………113
 Bibliografía: ……………………………………………………………………………………………
Análisis y Diseño de Sistemas I 2

PRESENTACIÓN
Esta guía didáctica es un material de ayuda institucional, perteneciente a las
especialidades de computación, Ingeniería de Software e Ingeniería de Redes y
Comunicaciones tiene por finalidad proporcionar los conocimientos de la
implementación y administración de Base de Datos en su primera parte.
La Organización SISE, líder en la enseñanza tecnológica a nivel superior, promueve

la elaboración de materiales educativos, en concordancia a las exigencias de las
tecnologías de estos tiempos, que permiten la creación de nuevas herramientas de
aprendizaje con el objetivo de facilitar el acceso de los estudiantes a la educación en
el marco del desarrollo tecnológico de la informática de las telecomunicaciones.
Esta guía contiene los conocimientos relacionados con el proceso de Ingeniería de

Software Orientado a Objetos. Se centra en el entendimiento del negocio, la captura
de requisitos y el análisis para desarrollar un sistema informático. En el desarrollo del
curso comprobará que el proceso de construcción de software empleando
metodologías y utilizando el Lenguaje Unificado de Modelado nos conduce al
desarrollo de un software con calidad.
El análisis de un modelo de negocio, permitirán que el alumno aplique todos los

conceptos.
Este material en su primera edición, servirá para ayudar a nuestros estudiantes

SISESINOS.

Arreglos
Contenidos
- Lección 1: Ingeniería de software

- Lección 2: RUP
- Lección 3: UML
____________________________________________________________________________

INGENIERÍA DE SOFTWARE
El término Ingeniería se define como un conjunto de conocimientos y técnicas que permiten
aplicar el saber científico a la utilización de la materia y de las fuentes de energía. Su aplicación
permite la utilización racional de los materiales y de los recursos naturales mediante
invenciones, construcciones y otras realizaciones provechosas para el hombre.
¿Qué es software de computadora?
El software es un elemento lógico del sistema que se desarrolla, no se estropea y en la

mayoría de casos se construye a medida. El software se define también como el producto que
abarca programas que se ejecutan dentro de una computadora de cualquier tamaño y
arquitectura, documentos que comprenden formularios e impresos y datos que combinan
números y texto, y también incluyen representaciones de información de audio, video e
imágenes.
¿Qué es la ingeniería de software?
La Ingeniería del Software es una disciplina o área de la informática o ciencias de la

computación, que ofrece métodos y técnicas para desarrollar y mantener software de calidad
que resuelven problemas de todo tipo.
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.

 El proceso del software
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
Cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de

calidad. El fundamento de la ingeniería del software es la capa de proceso. Los métodos de la
ingeniería del software indican cómo construir técnicamente el software. Las herramientas de la
ingeniería del software
Proporcionan un enfoque automático o semi-automático para el proceso y para los métodos,

Ej.: CASE.
Las fases genéricas de un proceso de software
Las fases genéricas del proceso del software son tres:
 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 ingeniería de sistemas o de información

- La planificación de proyectos de software
- Análisis de requisitos

 La fase de desarrollo
Se centra en el cómo. Durante el desarrollo, se intenta definir cómo han de diseñarse las
estructuras de datos, cómo ha de implementarse la función dentro de una arquitectura de
software, cómo han de implementarse los detalles procedí mentales, cómo han de
caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de programación y
cómo han de realzarse las pruebas. Las tres tareas específicas técnicas que tendrán lugar son:
- El diseño del software

- La generación de código
- Las pruebas de software
 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
Entre las actividades típicas de esta categoría se incluyen:
- Seguimiento y control del proyecto de software

- Revisiones técnicas formales que garanticen de calidad del software
- Gestión de configuración del software
- Preparación y producción de documentos
- Gestión de reutilización y de riesgos

Modelos de proceso de software
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.
A continuación se presentan los modelos de procesos para la ingeniería del software:
 El Modelo Lineal Secuencial

 El Modelo de Construcción de Prototipos
 El Modelo DRA
 Modelos Evolutivos de Proceso del Software:
o El modelo incremental
o El modelo espiral
o El modelo de desarrollo concurrente
 Desarrollo basado en componentes
MODELO LINEAL
Análisis Diseño Codificación Prueba
MODELO INCREMENTAL
A D C P Entregable o Incremental 1

MODELO PROTOTIPO

 Metodología de desarrollo de software
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.
 Metodologías de Desarrollo de Software Orientadas a Objetos

No es sorprendente que se proponga una visión orientada a objetos para la creación de
software de computadora, una abstracción que modela el mundo de forma tal que nos ayuda a
entenderlo y administrarlo mejor.
Entre las metodologías destacan:
- 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.
Una metodología ágil es la que tiene como principios que:
• 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.
Entre las metodologías ágiles destacan:
• Extreme Programming (XP)

• Método del Desarrollo Dinámico de Sistemas (DSDM)
• Desarrollo conducido por Características (FDD)
• ICONIX

Rational Unified Process (RUP)
RUP consiste en un conjunto de actividades necesarias para transformar los requerimientos de

usuario en el sistema de software.
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
b) Un modelo de proceso y una librería de contenidos asociados.
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.

c) Un meta-modelo de proceso básico
Posee elementos de definición de proceso para describir un proceso de ingeniería de software.

Está basado en el Proceso Unificado.
 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.
Fases del RUP
 Inicio: Define el alcance del proyecto.

 Elaboración: Se desarrolla el Plan del proyecto, la especificación de características y la
arquitectura base.
 Construcción: Construye el producto.
 Transición: Traslada el producto a la comunidad del usuario.

Workflows de RUP
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.
Existen dos grupos que son workflows técnicos y workflows de apoyo.
Organización por Componentes
Flujos de trabajo del proceso
 Modelo del Negocio: ¿cuál es el problema?

 Captura de requisitos: ¿Qué hace el sistema?
 Análisis: ¿Cómo funciona?
 Diseño: ¿cómo se construye?
 implementación: Archivos
 Pruebas
 Prueba en Servicio
Iteraciones
Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de

desarrollo completo que produce como resultado una entrega de producto ejecutable.

EL LENGUAJE DE MODELAMIENTO UNIFICADO - UML
El Lenguaje de Modelamiento Unificado (UML) es un lenguaje estándar que permite visualizar,
especificar, construir y documentar los artefactos del sistema de software. Este lenguaje puso
fin a la ―guerra de metodologías‖ dentro de la comunidad orientada a objetos. Esta orientación
a objetos fue inicialmente concebida por el lenguaje de programación Simula, pero no fue
popular hasta finales de los 80‘s con el advenimiento de los lenguajes de programación como
C++ y Smalltalk. Cuando la programación orientada a objetos se convirtió en un éxito, la
necesidad de metodologías para soportar el desarrollo de software continuó.
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.
La metodología de Booch, en flotación gráfica, es muy extensa. La metodología también

contiene un proceso mediante el cual un sistema es analizado tanto por un punto de vista de
mayor escala como de menor escala, y está basado en un proceso altamente iterativo e
incrementa.
- OMT: La Técnica de Modelamiento de Objetos (OMT) es una metodología desarrollada en

General Electric donde James Rumbaugh trabajó. El sistema es descrito por un determinado
número de modelos; el modelo de objetos, el modelo dinámico, el modelo funcional y el modelo
de casos de uso, los cuales se complementan entre ellos para dar la descripción completa del
sistema. La metodología OMT también contenía varias descripciones prácticas de cómo hacer
un diseño de sistemas, tomando en cuenta las concurrencias y relaciones con las bases de
datos relacionales.

- OOSE/Objectory: Las metodologías Object Oriented Software Engineering-OOSE y
Objectory, ambas fueron construidas con el mismo punto de vista básico postulado por Ivar
Jacobson. La metodología COSE (1. Jacobson, 1994) es la visión de Jacobson de una
metodología orientada a objetos. La metodología Objectory se utiliza para construir un
sinnúmero de sistemas, tan diversos como los sistemas de telecomunicaciones para Ericsson y
sistemas financieros para las compañías WalI Street. Ambas metodologías están basadas en
casos de uso, las cuales definen los requerimientos iniciales del sistema vistos por un actor
externo. Los casos de uso son luego implementados en todas las fases de desarrollo hasta
probar el sistema en el que son empleados para verificar el sistema. Objectory también ha sido
adaptado por la ingeniería de negocios, en la cual las ideas son empleadas para modelar y
mejorar los procesos de negocios.
- 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.
- CoadlYourdon: La metodología Coad/Yourdon, también conocida como OOAJOOD, fue uno

de los primeros métodos utilizados para el diseño y análisis orientado a objetos. La
metodología era bastante simple y fácil de aprender y, como tal, funcionaba bien para iniciar a
los novatos en las ideas y terminologías de la tecnología orientada a objetos. Sin embargo, la
flotación y metodología no podían aumentarse a una escala mayor, sino que funcionaban tan
sólo con sistemas muy limitados. En consecuencia, esta metodología es raramente utilizada
hoy en día.
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

tipo de discusiones, raramente había una buena respuesta, ya que todas las metodologías
tenían sus propias fortalezas y debilidades. Los desarrolladores con experiencia
frecuentemente tomaban una metodología como base, y luego tomaban ―prestado‖ algunas
ideas y soluciones de otras. En la práctica, la diferencia entre las metodologías no era tan
significativa, y a medida que el tiempo transcurría y las metodologías se desarrollaban, crecían
hasta parecerse entre ellas. Esto fue observado por mucho de los gurus en metodologías,
quienes empezaron a buscar formas de cooperar.
 HISTORIA DE UML
Grady Booch y James Rumbaugh, en Rational Rose Corporation, comenzaron su trabajo en

1994. Su meta fue crear una nueva metodología, ―Metodología
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.
Booch, Rumbaugh, y Jacobson lanzaron un número de

versiones preliminares de UML a la comunidad orientada a objetos. Esto les permitió
retroalimentarse y les dio muchas ideas y sugerencias para incorporarlas y así mejorar el
lenguaje. La versión 1.0 del Lenguaje de Modelamiento Unificado fue lanzada en enero de
1997 y actualmente se encuentra en la versión 2.0
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

 LENGUAJE DE MODELAMIENTO Y METODOLOGIA
Existen diferencias importantes entre una metodología y un lenguaje de modelamiento. Una
metodología es una forma explícita de estructurar nuestras acciones y pensamientos. Una
metodología le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo, y por qué hacerlo (el
propósito de una actividad específica). Las metodologías contienen modelos, y estos modelos
se usan para describir algo y para comunicar los resultados de la utilización de una
metodología. La principal diferencia entre una metodología y un lenguaje de modelamiento es
que el lenguaje de modelamiento carece de los procesos o instrucciones para saber qué hacer,
cómo hacerlo, cuándo hacerlo, y por qué hacerlo.
Cuando construimos modelos, también estructuramos nuestros pensamientos. Un modelo es

siempre un modelo de algo y éste tiene un propósito. Si el modelo no tiene un propósito
explícito, causará problemas, ya que nadie sabrá cómo o porqué usarlo. Un modelo se expresa
en un lenguaje de modelamiento. Un lenguaje de modelamiento contiene notaciones, los
símbolos usados en los modelos, y un conjunto de reglas que indican cómo hacerlo. Las reglas
son de sintaxis, semánticas, y pragmáticas.
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.
La revisión describe las diferentes partes del UML:

Vistas: Las vistas muestran los distintos aspectos de los sistemas a modelar. Una vista no es
un gráfico, sino una abstracción, la cual consiste en un número de diagramas. Sólo al definir un
determinado número de vistas, que muestran un aspecto en particular del sistema, puede
construirse una figura completa del sistema. Las vistas también vinculan el lenguaje de
modelamiento con el proceso / metodología elegida para el desarrollo.
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.
Mecanismos generales: Los mecanismos generales proveen comentarios adicionales,

información, o semánticas acerca de un elemento de modelo. También, proveen mecanismos
de extensión para adaptar y extender el UML a un proceso / metodología específica,
organización, o usuario.

 VISTAS
Modelar un sistema complejo es una tarea extensa. Un gráfico simple no puede capturar toda
la información necesaria para definir un sistema. Un sistema se describe con un número de
aspectos diferentes: funcional (su estructura estática e interacciones dinámicas), no funcional
(requerimientos oportunos, confiabilidad, implementación, etc.), y aspectos organizacionales
(organización del trabajo, elaboración de módulos de código, etc.).
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).
Estas vistas son:
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 Componentes o Implementación: Una vista que muestra la organización de los

componentes de código.

Vista de Concurrencia o Procesos: Una vista que muestra las concurrencias en el sistema y
encamina los problemas de comunicación y sincronización que están presentes en un sistema
con concurrencias.
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 Casos de Uso

La vista de Casos de Uso describe la funcionalidad que el sistema debería cumplir tal y como
es percibida por actores externos. Un actor interactúa con el sistema: puede ser un usuario o
algún otro sistema. La vista de casos de uso es para los clientes, diseñadores, desarrolladores,
y evaluadores. Está descrito en los diagramas de casos de uso y ocasionalmente en diagramas
de actividades. El uso que se desee del sistema se describe como una serie de casos de uso
en la vista de casos de uso, en el que un caso de uso es una descripción genérica de un uso
del sistema (una función requerida). La vista de casos de uso es céntrica. Esto quiere decir que
sus contenidos encaminan el desarrollo de las otras vistas. El objetivo final del sistema es
proveer la funcionalidad descrita en esta vista (junto con algunas propiedades no funcionales);
más aún, esta vista afecta a las otras. Esta vista es, también, empleada para validar y
finalmente verificar el sistema mediante la comprobación de la vista de casos de uso con los
clientes (se pregunta ―Es esto lo que desea‖) y se contrasta con el sistema no terminado (se
pregunta ―El sistema trabaja tal y como fue especificado‖).

 Vista Lógica
La vista lógica describe como la funcionalidad se provee. Es principalmente para diseñadores y
desarrolladores. En contraste con la vista de casos de uso, la vista lógica se enfoca en el
interior del sistema. Describe tanto la estructura estática (clases, objetos, y relaciones) como
las colaboraciones dinámicas que ocurren cuando, entre los objetos, se envían mensajes para
proveer una determinada función. Las propiedades tales como persistencia y concurrencias
también son definidas, así mismo las interfaces y la estructura interna de clases.
La estructura estática se describe en diagramas de objetos y clases. El modelamiento dinámico

se describe en diagramas de actividades, colaboración, secuencia y estado.
 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 Proceso
La vista de proceso tiene que ver con la división del sistema en procesos y procesadores. Este
aspecto, el cual es una propiedad no funcional del sistema, permite un uso de recursos
eficiente, la ejecución en paralelo y la manipulación de eventos asíncronos desde el entorno.
Detrás de la división del sistema, en hilos concurrentes de control ejecutables, la vista debe
también resolver la comunicación y sincronización de estos hilos. La vista de proceso es para
los desarrolladores e integradores del sistema y consiste de diagramas dinámicos (estado,
secuencia, colaboración, y diagramas de actividades).
 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.

 DIAGRAMAS
Los diagramas son los gráficos que realmente muestran los símbolos del modelo para ilustrar
aspectos o particularidades del sistema. Un modelo de sistema típicamente tiene varios
diagramas de cada tipo. Un diagrama es parte de una vista específica; y cuando es dibujado,
es usualmente asignado a una vista. Algunos tipos de diagrama pueden ser parte de varias
vistas, dependiendo de los contenidos del diagrama.
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 Casos de Uso

Un diagrama de casos de uso muestra un número de actores externos y su conexión a los
casos de uso que el sistema provee. Un caso de uso es la descripción de una funcionalidad (un
uso específico del sistema) que el sistema provee. La descripción del caso de uso real, es
normalmente, hecho en un archivo de texto plano como una propiedad de documentación del
símbolo de caso de uso, pero también puede ser descrita usando un diagrama de actividades.
Los casos de uso se describen sólo como son vistos externamente por el actor (el
comportamiento del sistema como el usuario lo percibe) y no describe como la funcionalidad es
provista dentro del sistema. Los casos de uso definen los requerimientos funcionales del
sistema.
 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.
Un sistema típicamente tiene un determinado número de diagramas de clases, no todas las

clases se insertan en un único diagrama de clases, y una clase puede participar en varios
diagramas de clases.

 Diagrama de Objetos
Un diagrama de objetos es una variante de un diagrama de clases y usa casi una flotación
idéntica. La diferencia entre ambos es que un diagrama de objetos muestra un número de
instancias de objetos de clases en vez de las clases reales. Por lo tanto, un diagrama de
objetos es un ejemplo de un diagrama de clases que muestra una posible imagen del sistema
en ejecución: cómo el sistema se vería en algún punto en el tiempo. Se usa la misma notación
de un diagrama de clases, con dos excepciones: los nombres de los objetos se subrayan y
todas las instancias en una relación se muestran.
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.

 Diagrama de Secuencias
Un diagrama de secuencias muestra una colaboración dinámica entre un número determinado
de objetos, como se muestra en la figura. El aspecto importante de este diagrama es que
muestra una secuencia de mensajes enviados entre objetos. También muestra una interacción
entre objetos, algo que pasará en algún punto específico en la ejecución del sistema. El
diagrama consiste en un determinado número de objetos mostrados con líneas verticales. El
tiempo transcurre en forma descendente en el diagrama el cual muestra el intercambio de
mensajes entre los objetos a medida que el tiempo transcurre en la secuencia o función. Los
mensajes se muestran como líneas con flechas que indican mensajes entre las líneas
verticales de los objetos. Las especificaciones del tiempo y otros comentarios se agregan en un
script a un costado del diagrama.
 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.
Los diagramas de colaboración se muestran como diagramas de objetos, donde un número

determinado de objetos se muestran junto con sus relaciones (al usar la notación del diagrama
de clases / objetos). Las flechas que representan mensajes se dibujan entre los objetos para
mostrar el flujo de mensajes entre los objetos. Los mensajes son rotulados, los cuales entre
otras cosas, muestran el orden en el cual los mensajes son enviados. Esto también puede
mostrar condiciones, iteraciones, valores de retorno, etc. Una vez que un desarrollador esté
familiarizado con la sintaxis de rotular mensajes, puede leer la colaboración, y seguir el flujo de
ejecución y el intercambio de mensajes. Un diagrama de colaboración también puede contener
objetos activos, aquellos que se ejecutan en forma concurrente con otros objetos.

 Diagrama de Actividades
Un diagrama de actividades muestra un flujo de secuencias de actividades. El diagrama de
actividades es típicamente utilizado para describir las actividades ejecutadas en una operación,
aunque también puede ser empleado para describir otros flujos de actividades, como un caso
de uso o una interacción. El diagrama de actividades consiste en estados de acciones, el cual
contiene. una especificación de una actividad a ser ejecutada (una acción). Un estado de
acción dejará el estado cuando la acción ha sido realizada (un estado en un diagrama de
estados necesita de un evento explícito antes de dejar el estado). Por lo tanto, el control fluye
entre los estados de acción, los cuales están conectados unos con otros. Las decisiones y
condiciones, así como también la ejecución paralela de estados de acción, también pueden ser
mostradas en el diagrama. El diagrama también puede contener especificaciones de mensajes
que son enviados o recibidos como parte de las acciones realizadas.

 Diagrama de Componentes
Un diagrama de componentes muestra la estructura física del código en términos de
componentes de código. Un componente puede ser un componente de código fuente, binario, o
ejecutable. Un componente contiene información sobre las clases lógicas o clases que
implementa: por lo tanto. crea una relación entre la vista lógica y la vista de componentes. La
dependencia entre los componentes se muestra y se hace más fácil analizar cómo otros
componentes se ven afectados por cambios en un componente. Los componentes también se
pueden mostrar con cualquiera de las interfaces que exponen, corno as interfaces OLE/COM;
además, pueden ser agrupadas en paquetes.
 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.
Como hemos dicho anteriormente, el diagrama de despliegue, mostrado en la vista de

despliegue, describe la arquitectura física actual del sistema. Esto es más que la descripción
funcional en la vista de casos de usos.

Arreglos
Contenidos
- Lección 1: Casos de Uso

- Lección 2: Actores / Caso de Uso
- Lección 3: Relación entre caso de uso
- Lección 4: Modelo de Negocio
____________________________________________________________________________

 CASOS DE USO
Un modelo de caso de uso es un modelo de como diferentes tipos de usuarios interactúan con
el sistema para resolver un problema. Como tal, este describe las metas de los usuarios, las
interacciones entre los usuarios y el sistema y el comportamiento requerido del sistema para
satisfacer esas metas.
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.
Elementos básicos del modelo

El modelo de caso de uso contiene, como mínimo, los siguientes elementos básicos del
modelo.
 Actor
Un elemento del modelo para representar cada actor. Las propiedades incluyen los nombres de
los actores y una breve descripción.

 Caso de Uso
Un elemento del modelo para representar cada caso de uso. Las propiedades incluyen el
nombre y la especificación del caso de uso.
 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.
Los propósitos del modelo del negocio son:
 Entender los problemas actuales de la organización

 Asegurarse que clientes, usuarios, desarrolladores y otros involucrados tengan igual
entendimiento de la empresa
 Proveer una vista estática de la estructura de la organización y una vista dinámica
dentro de los procesos de la organización.
Ejercicio: Caso PECSA:

PERUANA DE ESTACIONES DE SERVICIO S.A.C.
Proyecto de Sistema
Análisis Estratégico
Versión 1.5

HISTORIAL DE REVISIONES
FECHA DESCRIPCIÓN REVISADO POR: RÚBRICA
04-06-10 Javier Napán

Tabla de Contenido
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. Información del Negocio
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.2 Misión del Negocio:

Ser una empresa eficiente especializada en la distribución de
combustible, dirigida a satisfacer las necesidades de nuestros
clientes, brindando un servicio de calidad y un soporte
permanente q impulse sus ventas y enriquezca sus ofertas de
bienes y servicios en beneficio de los consumidores

2.3 Objetivos:
2.3.1 Estratégico:
El planeamiento estratégico de Peruana de
Estaciones de Servicio S.A.C. incluye planes de
desarrollo especificado como Ser una corporación
integrada, líder en proveer soluciones a los
requerimientos de energía de nuestros mercados,
ágil y anticipada al futuro y a la competencia, en
permanente búsqueda de nuevas oportunidades de
negocios, comprometida con la creación de valor
para nuestros clientes, personal, proveedores y
accionistas, en armonía con el medio ambiente y la
responsabilidad social.
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.

3. Organización:
3.1 Organigrama Funcional:
Administrador
Coordinador Administrativo
Coordinador Operativo
Jefe de Pista Mañana Jefe de Pista Tarde Jefe de Pista Noche
Representantes de Representantes de Representantes de
Servicio Servicio Servicio

Proyecto De Sistema
Modelo de Negocio
Versión 1.0

04-06-10 Modelo de Negocio Javier Napan

1. Descripción del Negocio:
Peruana de estaciones SAC, pertenece al Grupo PECSA; esta es una
corporación privada de capitales peruanos conformada por las empresas
Peruanas y se ha consolidado como la marca privada, completamente
peruana, más importante en la distribución y comercialización de
combustibles y derivados de hidrocarburos en el ámbito nacional. Las
actividades de la empresa que conforma el grupo está orientada a
brindar energía a empresas y personas a través de la distribución y
comercialización de gasolina, diesel, gas licuado de petróleo (GLP)
vehicular, gas natural vehicular (GNV) y lubricantes. Los diversos
productos de calidad que comercializa, el servicio diferenciado en
constante búsqueda de la excelencia y la eficiente capacidad de
distribución para llegar a todos los mercados que abastece, le permiten
al Grupo PECSA garantizar una estructura de negocio capaz de
desempeñarse con éxito en un mercado altamente competitivo.

2. Objetivos de Negocio:
El planeamiento estratégico de
Peruana de Estaciones de Servicio
S.A.C. incluye planes de desarrollo
especificado como Ser una
corporación integrada, líder en
proveer soluciones a los
requerimientos de energía de
nuestros mercados, ágil y anticipada
al futuro y a la competencia, en
permanente búsqueda de nuevas
oportunidades de negocios,
comprometida con la creación de
valor para nuestros clientes,
personal, proveedores y accionistas,
en armonía con el medio ambiente y
la responsabilidad social.
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.

3. Casos de Uso de Negocio:
Abastecimiento de Combustible
4. Actores de Negocios:
LVM Inversiones
PGN - Cálida

Arreglos
Contenidos
- Lección 1: Modelo de Análisis de Negocio

- Lección 2: Representar estructura y workflow de proceso de negocio
o Diagrama de Actividad
____________________________________________________________________________

 Modelo de Análisis de negocio
El modelo del análisis de negocio describe la realización de los casos del uso del negocio
modelando la interacción entre los trabajadores del negocio y las entidades de negocio.
El propósito del modelo del análisis de negocio es describir cómo se ejecutan los casos del uso
del negocio.
Elementos del análisis del negocio:
 Trabajadores del negocio identificados previamente.

 Entidades del negocio identificadas previamente.
 Asociaciones entre los trabajadores del negocio y las entidades del negocio.
 Diagramas de Realización:
o Diagrama de Clases de Negocio
o Diagrama de Actividades de procesos
 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.

 Son roles (humanos, software o hardware), no personas con nombres propios.
 Se encuentran dentro del negocio.
 No siempre un rol está asociado con el nombre de un cargo en la planilla de la
organización.
 El nombre no debe representar áreas, departamentos o partes de una organización.
 Cada trabajador debe participar en al menos un caso de uso del negocio. Si no
participa en ningún proceso debe ser eliminado del modelo.
 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.
Identificando una entidad de negocio:
 Participa por lo menos en un caso de uso.

 Pueden ser usadas por diferentes trabajadores del negocio en varios casos de uso del
negocio.
 Representan documentos, contratos, información solicitada, producto, conocimiento,
etc.
 Solo debe ser considerada información relevante y persistente al negocio.
 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.
Ejercicio: Caso PECSA

Proyecto De Sistema
Modelo de Análisis de Negocio
Versión 1.0

04-06-10 Modelo Análisis de Negocio Javier Napan

1. Entidades de Negocio
EN_Factura
EN_Guia de remision
EN_Formulario de descarga segura
EN_Historial de medición
EN_Inventario de medicion
EN_Reporte de ventas
EN_Lista de requerimientos
EN_Guia de conversion

2. Realizaciones de Caso de Uso
RCUN_Captura de
requerimientos y abstecimiento

3. Trabajadores de Negocio
TN_Jefe de pista
TN_Coordinador administrativo
TN_Coordinador operativo
TN_Administrador
TN_Representante de servicio

Arreglos
Contenidos
- Lección 1: Revisión de conocimientos / Proyectos de análisis
En esta semana, el instructor revisará los proyectos desarrollado por los alumnos, en el que se
debe crear y aplicar los conceptos estudiados.

Arreglos
Contenidos
- Lección 1: Requerimientos

 LA CAPTURA DE REQUISITOS
El esfuerzo principal en la fase de requisitos es desarrollar un modelo del sistema que se va a
construir. La utilización de los casos de uso es una forma adecuada de crear ese modelo. Esto
es debido a que los requisitos funcionales se estructuran de forma natural mediante casos de
uso.
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.
 PROPÓSITOS DE LOS CASOS DE USO

Los propósitos principales de los casos de usos son los siguientes:
- 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.
Un número diferente de personas tienen interés en los modelos de casos de uso.
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).

Los equipos de integración y de pruebas del sistema necesitan los casos de uso para evaluar
al sistema para asegurarse que cumpla con la funcionalidad especificada en los casos de uso.
Finalmente, cualquiera que esté involucrado en las actividades relacionadas a la funcionalidad

del sistema podría tener interés en los modelos de casos de uso. Esto podría incluir a los
equipos de marketing, lentas, soporte y documentació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.
El modelo de casos de uso es empleado no solamente para capturar requerimientos de nuevos

sistemas; también es utilizado cuando nuevas generaciones de sistemas son desarrolladas.
Cuando una nueva generación (versión) de un sistema es desarrollada, la nueva funcionalidad
es agregada al modelo de casos de uso existente insertando nuevos actores y casos de uso o
modificando las especificaciones de los actuales casos de uso.

 DIAGRAMA DE CASOS DE USO
Un modelo de casos de uso se describe en UML como un diagrama de casos de uso. Un
modelo de casos de uso puede ser dividido en una serie de diagramas de casos de uso. Un
diagrama de casos de uso contiene elementos de modelo para el sistema, los actores, los
casos de uso y muestra las distintas relaciones tales como generalización, asociación, Y
dependencia entre estos elementos. La descripción real de los contenidos de los casos de uso
usualmente se da en texto simple. Esta descripción contiene información vital para definir los
requerimientos y funcionalidades reales. Como una alternativa para describir los casos de uso
se usa el diagrama de actividades.
 COMPONENTES DE UN MODELO DE CASOS DE USO

Los componentes principales de un modelo de casos de uso son:
 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.

Los límites del sistema son definidos por la funcionalidad determinada por el sistema. La
funcionalidad se representa por un determinado número de casos de uso, y cada caso de uso
específica una funcionalidad completa. Cuando la funcionalidad se completa, el caso de uso
debe manejar la función completa, desde su inicialización por un actor externo hasta que éste
ha realizado la funcionalidad requerida. Un caso de uso debe devolver siempre algún valor al
actor, un valor sea cual sea lo que el actor desee del 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.

Encontrar a los Actores
Al identificar a los actores, establecemos a aquellas entidades interesadas en usar e

interactuar con el sistema. Luego es posible estar en la posición del actor para tratar de
identificar Tos requerimientos del actor en el sistema y qué casos de uso necesita el actor.
Los actores se pueden identificar respondiendo una serie de preguntas:
- ¿Quién usará la funcionalidad principal del sistema (actores principales)?
- ¿Quién necesitará apoyo del sistema para hacer sus tareas diarias?
- ¿Quién necesitará mantener, administrar, el sistema funcionando? (actores secundarios)
- ¿Qué dispositivos de hardware necesita manejar el sistema?
- ¿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.

La relaciones entre Actores
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.

 Casos de Uso
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.
Un caso describe la funcionalidad como un todo e incluye posibles alternativas, errores, y

excepciones que puedan ocurrir durante la ejecución del caso de uso. Se llama escenario a
una instancia de un caso de uso y esto representa el uso real del sistema (una ruta de
ejecución específica a través del sistema). Por ejemplo, una instancia de escenario del
caso de uso Contratar Seguro podría ser ‗John Doe contacta al sistema por teléfono y
adquiere un seguro para automóviles para el Toyota Corolla que acaba de comprar‖.

Encontrando Casos de Uso
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)?
Casos de Uso en UML
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.
Relaciones entre casos de uso
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 de generalización: Cuando un caso de uso padre es especializado en uno o más

casos de uso hijos que representan formas más específicas del caso de uso padre.
 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

muestra con una flecha punteada señalando al caso de uso del cual es extendido
con el estereotipo «extend».
 Relación lnclude.- Cuando un número de casos de uso tienen un comportamiento

en común, este comportamiento puede ser modelado en un único caso de uso que
es empleado por otros casos de uso. Cuando un caso de uso base utiliza a uno
incluido significa que este último debe ser utilizado en su totalidad. El caso de uso
incluido devuelve la respuesta a una solicitud. El caso de uso incluido es un tipo de
caso de uso abstracto.
Una relación include se muestra a través de una flecha punteada señalando al

caso de uso que está siendo utilizado con el estereotipo«include».
 Relación de Generalización.- Es utilizada cuando se encuentra que dos o más

casos de uso tienen comportamiento, estructura y propósito común. Para
representar esto se plasma la parte común en un nuevo caso de uso que será
especializado por los casos de uso hijos. Ni el caso de uso padre ni los casos de
uso hijo son abstractos, a pesar que la mayor parte de veces el caso de uso padre
es abstracto.

 Plantilla de Especificaciones de Casos de Uso
La descripción del caso de uso es normalmente mediante un texto de descripción. Esto es
una especificación consistente y simple sobre cómo los actores y los casos de uso (el
sistema) interactúan. Se concentra en el comportamiento externo del sistema e ignora
cómo las cosas se ejecutan realmente dentro del sistema. El lenguaje y terminología
empleada en la descripción es la misma empleada por el usuario/cliente del sistema.
La descripción del texto debería incluir:
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.
Como complemento para la descripción de un caso de uso que contiene la descripción

completa y general se emplean un número de escenarios reales para ilustrar qué sucedería
cuando el caso de uso es inicializado. La descripción del escenario ilustra un caso
específico, con ambos, actores y casos de uso, involucrados como instancias reales. Los
usuarios pueden entender mejor un caso de uso complejo cuando un escenario más
práctico describe el comportamiento del sistema. Pero note, que una descripción de un
escenario es un complemento, no un sustituto para la descripción del caso de uso.
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.
Se presenta la plantilla de especificaciones de caso de uso:
Ejemplo:
Modelo de Caso de uso: CASO REPSOL

Proyecto De Sistema
Modelo de Caso de Uso
Versión 1.0

04-06-10 Modelo caso de uso Javier Napan

1. Casos de Uso

2. Especificaciones de Casos de Uso

Arreglos
Contenidos
- Lección 1: Diagrama de clases

____________________________________________________________________________

 Diagrama de clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran
el sistema, las cuales pueden ser asociativas, de herencia, de uso y de instanciamiento.
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.
Representación de: - Requerimientos en entidades y actuaciones. - La arquitectura

conceptual de un dominio - Soluciones de diseño en una arquitectura - Componentes de
software orientados a objetos
Un diagrama de clases esta compuesto por los siguientes elementos:
 Clase: atributos, métodos y visibilidad.

 Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos
 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:
 Superior: Contiene el nombre de la Clase

 Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase
(pueden ser private, protected o public).
 Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa
el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).
Ejemplo:
Una Cuenta Corriente que posee como característica:

 Balance
Puede realizar las operaciones de :
 Depositar
 y Balance
El diseño asociado es:

 Atributos y Métodos:
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).
 Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden
interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la

cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada
extremo de la relación y éstas pueden ser:
 uno o muchos: 1..* (1..n)

 0 o muchos: 0..* (0..n)
 número fijo: m (m denota el número).
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:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir,
Auto posee las Características de Vehículo (Precio, VelMax, etc) además
posee algo particular que es Descapotable, en cambio Camión también hereda
las características de Vehiculo (Precio, VelMax, etc) pero posee como
particularidad propia Acoplado, Tara y Carga.
Cabe destacar que fuera de este entorno, lo único "visible" es el método

Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene
definición pública, en cambio atributos como Descapotable no son visibles por
ser privados.
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).

Ejemplo:
En donde se destaca que:
Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee
las referencias).
Cuando se destruye el Objeto Almacén también son destruidos los objetos

Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.
La composición (por Valor) se destaca por un rombo relleno.
La agregación (por Referencia) se destaca por un rombo transparente.
La flecha en este tipo de relación indica la navegabilidad del objeto

referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.
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:
Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una

orden de compra solo puede tener asociado un cliente.
Dependencia o Instanciación (uso):
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):

Ejemplo:
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:
Una clase parametrizada se denota con un subcuadro en el extremo superior

de la clase, en donde se especifican los parámetros que deben ser pasados a
la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso
de un Diccionario en donde una llave o palabra tiene asociado un significado,
pero en este caso las llaves y elementos pueden ser genéricos. La genericidad
puede venir dada de un Template (como en el caso de C++) o bien de alguna
estructura predefinida (especialización a través de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos

dependerán exclusivamente de la implementación que se le quiera dar.

Arreglos
Contenidos
- Lección 1: Modelo Conceptual

- Lección 2: Análisis y Tecnología orientada a objetos.
- Lección 3. Aplicación.
____________________________________________________________________________

UML Y LA PERSISTENCIA
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
Un modelo conceptual explica los conceptos significativos en un dominio del problema. Es el

artefacto más importante a crear durante el análisis orientado a objetos. Identificar muchos
objetos o conceptos constituye la esencia del análisis orientado a objetos, y el esfuerzo se
compensa con los resultados conseguidos durante la fase de diseño e implementación.
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.
El paso esencial de un análisis o investigación orientada a objetos es descomponer el

problema en conceptos u objetos individuales: las cosas que sabemos. Un modelo conceptual
es una representación de conceptos en un dominio del problema. En el UML, se ilustra con un
grupo de diagramas de estructura estática donde no se define ninguna operación.
La designación de modelo conceptual ofrece la ventaja de subrayar fuertemente una

concentración en los conceptos del dominio, no en las entidades del software.
Puede mostrarnos:
 Conceptos
 Conceptos entre conceptos
 Atributos de conceptos.

Por ejemplo, en la figura vemos un modelo conceptual parcial del dominio de la tienda y las
ventas. Explica gráficamente que el concepto de Pago y Venta son importantes en este
dominio del problema, que Pago se relaciona con Venta en una forma que conviene señalar y
que Venta tiene fecha y hora. Por ahora no son importantes los detalles de la notación.
Conocimiento de la nomenclatura del dominio
Además de descomponer el espacio del problema en unidades comprensibles (conceptos), la

creación de un modelo conceptual contribuye a esclarecer la terminología o nomenclatura del
dominio. Podemos verlo como un modelo que comunica (a los interesados como pueden serlo
los desarrolladores) cuáles son los términos importantes y cómo se relacionan entre sí.
Los modelos conceptuales no son modelos de diseño de software
Un modelo conceptual es una descripción del dominio de un problema real. No es una

descripción del diseño del software, como una clase de Java o de C++. Por ello, los siguientes
elementos NO son adecuados en él:
 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:
 Símbolo: palabras o imágenes que representan un concepto.

 Intención: la definición del concepto.
 Extensión: el conjunto de ejemplos a que se aplica el concepto.
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.

Cuando se crea un modelo conceptual, por lo regular la vista del símbolo y de la
Intención de un concepto es el aspecto de mayor interés práctico.
Los modelos conceptuales y la descomposición
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.
Una distinción fundamental entre el análisis orientado a objetos y el análisis estructurado es la

división por conceptos (objetos) y no por funciones.
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.
Conceptos en el dominio del punto de venta
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.
Estrategias para identificar los conceptos
Nuestra meta es crear un modelo conceptual de conceptos interesantes o significativos del

dominio en cuestión. En este caso, ello significa conceptos relacionados con la Compra de
productos. La tarea fundamental será, pues, identificar los conceptos; se proponen dos
estrategias.
La siguiente es una directriz de gran utilidad en la identificación de conceptos:
Es mejor exagerar y especificar un modelo conceptual con muchos conceptos refinados que
no especificarlo cabalmente
No piense que un modelo conceptual es más adecuado si tiene menos conceptos.

Generalmente suele suceder lo contrario.
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.
No se excluya un concepto simplemente porque los requerimientos no indiquen una necesidad

evidente que permita recordar la información acerca de ella (criterio común de la construcción
de modelos de datos para diseñar una base de datos relacional, pero no pertinente a la
creación de modelos conceptuales) o porque el concepto carezca de atributos. Es

perfectamente válido tener conceptos sin atributos o conceptos con un papel puramente de
comportamientos en el dominio en vez de un papel informal.
 Obtención de conceptos a partir de una lista de categorías de conceptos.

La creación de un modelo conceptual se comienza preparando una lista de conceptos idóneos
a partir de la siguiente lista. Contiene muchas categorías comunes que vale la pena tener en
cuenta, sin que importe el orden de importancia. Los ejemplos se tomaron de los dominios de
la tienda y de las reservaciones de líneas aéreas.
Categoría del concepto Ejemplos
Objetos físicos o tangibles TPDV, Avión
Especificaciones, diseño o descripciones de EspecificaciónProducto, Descripción de Vuelo

cosas
Lugares Tienda, Aeropuerto
Transacciones Venta, PagoReservación
Línea o rengión de elemento de VentasLíneadeProducto

transacciones
Papel de las personas Cajero, Piloto
Contenedores de otras cosas Tienda, Cesto, Avión
Cosas dentro de un contenedor Producto Pasajero
Otros sistemas de cómputo o SistemaAutorizacióndeTarjetadeCrédito,

electromecánicos externos al sistema ControldeTráficoAéreo
Conceptos de nombres abstractos Hambre Acrofobia
Organizaciones DepartamentosdeVentas, ObjetoLineaAérea
Eventos Venta, Robo, Junta Vuelo Accidente,

Aterrizaje
Procesos (a menudo no están representados VentaUnProducto, ReservaciónAsiento

como conceptos, pero pueden estarlo)
Reglas y políticas PolíticasdeReembolso,

PoliticasdeCancelaciones
Catálogos DepartamentosdeVentas, ObjetoLineaAérea

Obtención de conceptos a partir de identificación, de frases nominales
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.
3. El Sistema determina el precio del producto y a la transacción de ventas le agrega la

información sobre el producto. Se muestran la descripción y el precio del producto actual.
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.
 Conceptos idóneos para el dominio del punto de venta

A partir de la lista de categoría de conceptos y del análisis de frases nominales, generamos
una lista de conceptos adecuados para incluirlos en la aplicación del punto de
venta: La lista está sujeta a la restricción de los requerimientos y simplificaciones que se

consideren en el momento.
TPDV EspecificacióndeProducto
Producto VentasLíneadeProductos
Tienda Cajero
Venta Cliente
Pago Gerente

Objetos del informe: ¿Se incluye el recibo en el modelo?
El recibo es un registro de una venta y de un pago, así como un concepto relativamente

prominente en el dominio de ventas; ¿debe, pues, mostrarse en el modelo? En seguida se
mencionan algunos factores que han de tenerse presentes:
 El recibo es un informe de una venta. En general, no conviene incluirlo en un modelo

conceptual, ya que toda su información proviene de otras fuentes. Este es un buen
motivo para excluirlo
 El recibo cumple un papel especial respecto a las reglas de la empresa: al portador le
confiere el derecho de devolver los productos adquiridos. Esta es una razón para
incorporarlo al modelo.
El recibo se excluirá, porque las devoluciones se productos no se incluyen en este ciclo de

desarrollo. Se justificará su inclusión durante el ciclo que aborde la Devolución de productos.
El modelo conceptual del punto de venta (solo conceptos)
La lista anterior de los nombres de conceptos puede representarse gráficamente en la notación

del diagrama de estructura estática de UML, a fin de mostrar la génesis del modelo conceptual

 Directrices para construir modelos conceptuales
Cómo construir un modelo conceptual
Aplique los siguientes pasos para crear un modelo conceptual:
Para construir un modelo conceptual:
1. Liste los conceptos idóneos usando la Lista de categorías de conceptos y la Identificación

de la frase nominal relacionada con los requerimientos en cuestión.
2. Dibújelos en un modelo conceptual.
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.
La asignación de nombres y el modelado de las cosas: el cartógrafo
La estrategia del cartógrafo se aplica a los mapas y a los modelos conceptuales.
Prepare un modelo conceptual inspirándose en la metodología del cartógrafo:
 Utilice los nombres existentes en el territorio.

 Excluya las características irrelevantes.
 No agregue cosas que no existan.
El modelo conceptual es una especie de mapa de conceptos o cosas de un dominio. Este

enfoque pone de relieve el papel analítico de un modelo conceptual y sugiere lo siguiente:
• 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.

• Un cartógrafo no muestra cosa que no existan. Por ejemplo, una montaña inexistente. En
forma parecida, el modelo conceptual ha de excluir las cosas que no se encuentren en el
dominio del problema en cuestión
1.8.3 Un error que se comete frecuentemente al identificar los conceptos
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:
Si en el mundo real no consideramos algún concepto X como número o texto probablemente X

sea un concepto y no un atributo.
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?
En el mundo real, un aeropuerto de destino no se considera número ni texto: es una cosa

masiva que ocupa espacio. Por tanto, Aeropuerto debería ser un concepto.
En caso de duda, convierta el atributo en un concepto independiente
Conceptos similares: comparación entre TPDV y Registro
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?
Primero, una regla práctica consiste en que un modelo conceptual no es absolutamente

correcto ni erróneo, sino de mayor o menor utilidad; es una herramienta de la comunicación.
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.
Construcción de un modelo del mundo irreal
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.

Enumeramos algunos conceptos adecuados que se relacionan con un intercambio de
telecomunicaciones: Mensaje, Conexión, Diálogo, Ruta, Protocolo.
Especificación o descripción de conceptos
Suponga lo siguiente:
La instancia de Elemento representa una entidad física de una tienda.
Puede ser incluso un número serial.
Un Elemento tiene una descripción, precio y código universal de producto, los cuales no están
registrados en ninguna otra parte.
Todos los que trabajan en ¡a tienda sufren amnesia
Cada vez que se vende un elemento físico, en ―terreno del software‖ se elimina una instancia
del software correspondiente a Elemento.
Con estas suposiciones, preguntamos: ¿qué sucede en el siguiente escenario?
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.
Necesidad de las especificaciones
El problema anterior demuestra la necesidad de un concepto de objetos que son

especificaciones o descripciones de otras cosas. Para resolver el problema del Elemento lo que
se necesita es una EspecificaciónProducto (o Especificación Elemento,
DescripciónProducto,...) concepto que registra la información sobre los elementos. Una
EspecificaciónProducto no representa un Elemento, sino una descripción acerca de ellos.
Nótese que, aunque todos los elementos inventariados se vendan y se eliminen sus instancias
correspondientes de software, se conserva la EspecificaciónProducto.
La descripción o especificación de objetos se relacionan bastante con aquella que describen.

En un modelo conceptual, se acostumbra estipular que una EspecificaciónX describe una X
Especificaciones de otras cosas. La EspecificacióndeProducto puede

describir muchos Productos

La necesidad de especificar los conceptos es frecuente en los dominios de ventas y productos.
También lo es en la manufactura, donde se requiere una descripción de lo manufacturado que
se distingue del elemento manufacturado. El tiempo y el espacio han sido incluidos al explicar
la causa de la especificación de conceptos, por ser muy comunes; no se trata de un concepto
poco usual de la construcción de modelos.
¿Cuándo se requiere especificar los conceptos?
Las siguientes directrices indican cuando emplear las especificaciones.
Incorpore una especificación o descripción de conceptos (por ejemplo EspecificaciónProducto)

cuando:
 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
Otro ejemplo de especificación
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.
.Para resolver este problema, se requiere una DescripcióndeVuelo (o EspecificacióndeVuelo)

que describa un vuelo y su ruta, aún cuando no esté programado un vuelo determinado.

Aplicación:
Caso: REPSOL (Modelo Conceptual)

Proyecto De Sistema
Modelo Conceptual
Versión 1.0

04-06-10 Modelo conceptual Javier Napan

1. Diagrama de Clases

2. Diagramas de Estado
CLS_Administrador
recibiendo inventario
de medicion
evaluando inventario
de medicion
generando lista de
requeriminetos
enviando lista de
requerimientos

CLS_Coordinador_Administrativo
recibiendo inventario
de medicion
revisando inventario
de medicion
entregando inventario
de medicion

CLS_Coordinador_Operativo
recibiendo historial
de medicion
revisando historial
de medicion
comparando con el
reporte de ventas
generando inventario
de medicion

CLS_Jefe_Pista
realizando
medicion diaria
generando historial
de medicion
firmando
consultando guia de factura y guia
conversion
completando formulario
completando historial de descarga segura
de medicion
entregando historial realizando la

de medicion medicion final
recibiendo revisando el
factura y guia contenedor del camion
realizando la generando formulario de

primera medicion descarga segura
revisando la calidad anulado

de los combustibles abastecimiento

CLS_Factura
entregando
recibiendo
consultando
firmando

CLS_Formulario_Descarga_Segura
generando
completando
enviando
recibiendo
firmando
CLS_Guia_Conversion
consultando

CLS_Guia_Remision
entregando
recibiendo
consultando
firmando

CLS_Historial_Medicion
generando
completando
enviando
recibiendo

CLS_Inventario_medicion
generando
revisando
anulando
CLS_Lista_requerimientos
genenerando
enviando
recibiendo

CLS_Proveedor
recibiendo lista de
requerimientos
entregando
factura
entregando guia de
remision
abasteciendo
firmando formulario de
descarga segura
CLS_Reporte_ventas
consultando
comparando

3. Diagrama de Colaboración

4. Diagrama de Secuencia

Arreglos
Contenidos
- Lección 1: Repaso de contenido

- Lección 2: Integración de conocimientos.
- Lección 3. Sustentación de proyectos.
____________________________________________________________________________


Manual ADSIv15

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Manual ADSIv15

Încărcat de

Drepturi de autor:

Formate disponibile

 Presentación…………………………………………………………………………………………..

 Semana 1: Conceptos generales.......................................…………......……...4

 Semana 2: Casos de Uso......…........................................................................28

 Semana 3: Caso práctico dirigido..................................................…..………28

 Semana 4: Diagramas Complementarios......….............…………........….………42

 Semana 5: Revisión de conocimiento…….........................................…….....52

 Semana 7: Diagramas de clases ………………………………...............…………….79

 Semana 8: Caso Práctico – Aplicación diagrama de clases.…………….………..86

 Semana 9: Repaso de conocimiento……….....................................…………113

Análisis y Diseño de Sistemas I 2

La Organización SISE, líder en la enseñanza tecnológica a nivel superior, promueve

Esta guía contiene los conocimientos relacionados con el proceso de Ingeniería de

El análisis de un modelo de negocio, permitirán que el alumno aplique todos los

Este material en su primera edición, servirá para ayudar a nuestros estudiantes

Análisis y Diseño de Sistemas I 3

- Lección 1: Ingeniería de software

Análisis y Diseño de Sistemas I 4

¿Qué es software de computadora?

El software es un elemento lógico del sistema que se desarrolla, no se estropea y en la

¿Qué es la ingeniería de software?

La Ingeniería del Software es una disciplina o área de la informática o ciencias de la

Análisis y Diseño de Sistemas I 5

Cualquier enfoque de ingeniería debe apoyarse sobre un compromiso de organización de

Proporcionan un enfoque automático o semi-automático para el proceso y para los métodos,

Las fases genéricas de un proceso de software

Las fases genéricas del proceso del software son tres:

- La ingeniería de sistemas o de información

Análisis y Diseño de Sistemas I 6

- El diseño del software

Entre las actividades típicas de esta categoría se incluyen:

- Seguimiento y control del proyecto de software

Análisis y Diseño de Sistemas I 7

A continuación se presentan los modelos de procesos para la ingeniería del software:

 El Modelo Lineal Secuencial

Análisis Diseño Codificación Prueba

Análisis y Diseño de Sistemas I 8

Análisis y Diseño de Sistemas I 9

 Metodologías de Desarrollo de Software Orientadas a Objetos

Entre las metodologías destacan:

Una metodología ágil es la que tiene como principios que:

Entre las metodologías ágiles destacan:

• Extreme Programming (XP)

Análisis y Diseño de Sistemas I 10

RUP consiste en un conjunto de actividades necesarias para transformar los requerimientos de

b) Un modelo de proceso y una librería de contenidos asociados.

Análisis y Diseño de Sistemas I 11

Posee elementos de definición de proceso para describir un proceso de ingeniería de software.

Fases del RUP

 Inicio: Define el alcance del proyecto.

Análisis y Diseño de Sistemas I 12

Existen dos grupos que son workflows técnicos y workflows de apoyo.

Organización por Componentes

Flujos de trabajo del proceso

 Modelo del Negocio: ¿cuál es el problema?

Cada fase en RUP puede descomponerse en iteraciones. Una iteración es un ciclo de

Análisis y Diseño de Sistemas I 13

La metodología de Booch, en flotación gráfica, es muy extensa. La metodología también

- OMT: La Técnica de Modelamiento de Objetos (OMT) es una metodología desarrollada en

Análisis y Diseño de Sistemas I 14

- CoadlYourdon: La metodología Coad/Yourdon, también conocida como OOAJOOD, fue uno

Análisis y Diseño de Sistemas I 15

Grady Booch y James Rumbaugh, en Rational Rose Corporation, comenzaron su trabajo en

Booch, Rumbaugh, y Jacobson lanzaron un número de

Análisis y Diseño de Sistemas I 16