Escuela Profesional de

Ingenieria de Sistemas
SESION 2:
Introduccin a la Orientacin de Objetos

Docente : Mg. Nancy Bernardo Lizarbe

PROCESOS DE NEGOCIOS

PROCESOS DE NEGOCIOS

Un proceso de negocios es un conjunto de pasos o

actividades relacionadas en las que intervienen gente,
informacin y otros recursos para crear valor.
Los procesos de negocios se integran de pasos que se
pueden identificar en el tiempo y el espacio
Tiene un principio y un fin
Tienen entradas y salidas

Modelado de Procesos de Negocios

El

modelado de procesos es esencial en

el desarrollo de los sistemas de
informacin ya que nos ayuda a
identificar el problema que el sistema de
informacin deber resolver y la manera
en como deber resolverlo

Qu es el Modelado del Negocio?

Es una tcnica para modelar procesos del negocio.

El Modelo de negocio provee una manera de expresar los

procesos del negocios en trminos de actividades del
negocio y comportamiento colaborativo.

INPUT

OUTPUT

EMPRESA

BPMN Business Process Modeling Notation

El objetivo principal de desarrollar BPMN es proveer
una notacin que sea fcilmente entendible por todos
los usuarios de negocio.
Desde los analistas que crean los borradores iniciales
de procesos hasta los desarrolladores tcnicos que son
responsables de implementar la tecnologa que
ejecutar dichos procesos. Y por supuesto, la gente de
negocio que manejar y monitorear estos procesos.

Por qu es importante Modelar con BPMN?

BPMN es un estndar internacional de modelado de procesos
aceptado por la comunidad.
BPMN es independiente de cualquier metodologa de
modelado de procesos.
BPMN crea un puente estandarizado para disminuir la brecha
entre los procesos de negocio y la implementacin de estos.
BPMN permite modelar los procesos de una manera unificada y
estandarizada permitiendo un entendimiento a todas las
personas de una organizacin.

Introduccin a BPMN
Business Process Modeling Notation BPMN proporciona un lenguaje
comn para que las partes involucradas puedan comunicar los
procesos de forma clara, completa y eficiente.
BPD es un Diagrama diseado para representar grficamente la
secuencia de todas las actividades que ocurren durante un proceso,
basado en la tcnica de Flow Chart, incluye adems toda la
informacin que se considera necesaria para el anlisis.
BPD es un Diagrama diseado para ser usado por los analistas de
procesos, quienes disean, controlan y gestionan los procesos.

Introduccin a BPMN
Solicitud de Crdito de Consumo.

Elementos
Un BPD (diagrama de procesos de negocio) se estructura
con un grupo de elementos grficos.
Las cuatro categoras bsicas de elementos son:

Flow Objects (objetos de flujo)

Connecting Objects (objetos de conexin)
Swimlanes (Carriles)
Artifacts (artefctos)

Flow Objects (Objetos de Flujo)

Un BPD tiene un pequeo grupo de elementos centrales
(tres), los cuales son los Flow Objects:
-

Event (Evento)

Activity (Actividad)

- Gateway (Decisin)

Flow Objects: Evento

Un evento se representa por un circulo y es algo que
sucede durante el curso de un proceso de negocio.
Los eventos afectan el flujo del proceso y usualmente
tienen un causa (trigger - gatillo) o un impacto (result
resultado).
Los eventos se representan con crculos con el centro
abierto para permitir anotar diferentes gatillos o
resultados.

Flow Objects: Event

Hay tres tipos de eventos basado en cundo ellos
afectan el flujo:
- Start (comienzo)
- Intermediate (intermedio)
- End (final)

Flow Objects: Actividad

Una actividad (Activity) se representa por un
rectngulo con sus bordes redondeados y es un
trmino genrico para el trabajo que un organizacin
realiza.
Un actividad puede ser atmica o no atmica
(compuesta).

Flow Objects: Actividad

Los tipos de actividades son:
- Task (tareas)

- Sub-process (subproceso)

Los subprocesos se distinguen por un pequeo + al centro y

abajo en la figura.

Flow Objects: Gateway

Un Gateway es representado por la figura de un
diamante y se usa para controlar la divergencia de la
secuencia de un flujo.
Determina las tradicionales decisiones, tanto de
bifurcaciones, como uniones y acoplamientos de
flujos.
Las anotaciones al interior indican el tipo de
comportamiento de control.

Connecting Objects
Los objetos de flujo se conectan entre ellos en un
diagrama para crear el esqueleto bsico de la
estructura de un proceso de negocio.
Existen tres Connecting Objects que proveen esta
funcin de conexin.
- Sequence Flow
- Message Flow
- Association

Connecting Objects: Sequence Flow

Un Sequence Flow se representa por una lnea slida
con el extremo slido
Es usada para mostrar el orden (secuencia) de la
actividad dentro del proceso.
Note que el trmino control flow generalmente no es
usado en BPMN.

Connecting Objects: Message Flow

Un Message Flow se representa por una lnea
segmentada con el extremo sin relleno.
Es usada para mostrar el flujo de mensajes entre dos
participantes de procesos separados (business entities o
business roles).

En BPMN, dos Pools en el diagrama representan a

dos participantes.

Connecting Objects: Association

Una Association se representa por una
segmentada finamente con el extremo en punta.

lnea

Se usa para asociar datos, textos u otros artefactos con

flujos de objetos.
Las asociaciones son usadas para mostrar las entradas
y salidas de las actividades.

Ejemplo con formas bsicas

Ejemplo de Proceso de Negocio Simple

Ejemplo con formas bsicas y marcas internas en las

formas

Segmento de un Proceso con ms detalles

Swimlanes
Muchas tcnicas de modelados utilizan el concepto de
swimlanes como mecanismo de organizacin de
actividades en categoras visuales separadas para
ilustrar las diferentes capacidades funcionales o
responsabilidades.
BPMN soporta swimlanes con dos constructores
principales:
- Pool
- Lane

Swimlanes : Pool
Un Pool representa un Participante en un Proceso.

Nombre

El Pool tambin acta como contenedor grfico para

separar al grupo de actividades realizadas por un
participante de otros Pools. Los Pools se usan
generalmente en el contexto de situaciones B2B.

Swimlanes : Lane
Un Lane es una particin dentro de un pool y se
extiende a lo largo de todo el pool, tanto vertical como
horizontalmente.

Nombre
Nombre

Nombre

Los Lanes son usados para organizar y categorizar

actividades.

Swimlanes : Pool & Lane

Los Pools se usan cuando los diagramas involucran a
dos entidades de negocios o participantes separados.
Estn fsicamente separados en el diagrama.

Las actividades dentro de Pools separados son

consideradas auto contenidas en el proceso. De esta
forma, la secuencia del flujo podra no atravesar el lmite
del Pool.

Swimlanes : Pool & Lane

Los flujos de mensajes son los mecanismos que
muestran la comunicacin entre dos participantes,
conectando de esta manera a dos Pools (u objetos
dentro de los Pools).

Swimlanes : Pool & Lane

Ejemplo de BPD con Pools

Swimlanes : Pool & Lane

Los Lanes son ms cercanos a los swimlanes que
tradicionalmente se utilizan para modelar procesos de
negocio.
Los Lanes son usados para separar actividades
asociadas con una funcin especfica de la organizacin.
La secuencia de flujos podra atravesar los lmites del
Lane dentro de un Pool, pero podran no usarse flujos de
mensajes entre Flow Objects en Lanes del mismo Pool.

Swimlanes : Pool & Lane

Segmento de un Proceso con Lanes

Elementos : Artifacts
BPMN fue diseado para permitir a los modeladores y
herramientas de modelado algunas flexibilidades para
extender la notacin bsica y proveer la habilidad poder
modelar diferentes contextos apropiadamente.
No est limitado el nmero de Artefactos que se pueden
agregar a un diagrama para que ste represente ms
apropiadamente al contexto del negocio.
La versin actual de BPMN predefine slo tres tipos de
artefactos.

Elementos : Artifacts
Data object
Nombre
[Estado]

Group

Annotation

Anotaciones de Texto
permiten al Modelador agregar
informacin adicional

Artifact : Data Object

Los Data Objects son un mecanismo para
mostrar como las actividades requieren o
producen objetos.
Se conectan a las actividades a travs de
asociaciones.

Nombre
[Estado]

Artifact : Group
Un Group es representado por un
rectngulo redondeado dibujado con
lnea segmentada
El agrupamiento puede ser usado para
propsitos de documentacin o anlisis,
y no afecta la secuencia del flujo.

Artifact : Annotation
Las Annotations son mecanismos
para que un modelador pueda
agregar informacin textual adicional
para el lector del diagrama BPMN.

Anotaciones de Texto
permiten al Modelador agregar
informacin adicional

Artifact
Los modeladores puede crear sus propios tipos de
artefactos que agreguen ms detalle al proceso.
Con bastante frecuencia se muestran entradas y salidas
de actividades en los procesos. Sin embargo, la
estructura bsica del procesos, es especificada con
actividades, gateways, y flujos de secuencia.

Artifact

Segmento de un Proceso con

Lanes. Sin artefactos.

Segmento de un Proceso con Lanes.

Con artefactos.

Elementos centrales de los diagramas

Lista completa de elementos

EJEMPLO

40

CASO 1 - BPMN

41

Para comprar un producto es necesario colocar

una orden de pedido, luego sta es procesada
mediante la verificacin de la orden, retiro de los
productos del inventario y empaque del pedido,
para proceder a su envo y facturacin.

CASO 2 - BPMN

42

Un empleado enva una informacin para ser

revisada. A un gerente se le enva la informacin
para su revisin, quin tiene la potestad de
aprobarla o rechazarla. Si se aprueba, el
empleado recibe una notificacin y el proceso
culmina. De lo contrario al empleado se le enva la
informacin para su correccin. El empleado
procede a realizar los cambios y a enviar la
informacin de vuelta. Luego se enva una
notificacin al gerente y el proceso culmina.

Definicin de Requerimientos

43

Cuando un Cliente solicita que se desarrolle un sistema

tiene algunas nociones de lo que debe hacer.
Por esta razn cada sistema basada en software tiene un
propsito, usualmente expresado con algo que el sistema
debe hacer.
Un requerimiento es una caracterstica del sistema
o una descripcin de algo que el sistema es
capaz de hacer con el objeto de satisfacer el
propsito del sistema

Definicin de Requerimientos

44

Es decir, los requerimientos son lo que los clientes/usuarios

esperan que haga el sistema.
Los analistas, por lo tanto, deben entender el problema de
los usuarios en su cultura y en su lenguaje y construir el
sistema que resuelve sus necesidades.
En si el objetivo del anlisis de requerimientos es resolver el
problema.

Requerimientos v/s Diseo

45

Los Requerimientos definen el QU (el problema) del

sistema
El Diseo define el COMO (la solucion)
Durante el anlisis de requerimientos no se consideran
descripciones especificas de la implementacion como
requerimientos, a menos que el cliente lo pida (Ejm. Base de
datos, lenguajes de programacin, etc)
Los requerimientos, por lo tanto deben centrarse en el
cliente/usuario y el problema.

Importancia de los Requerimientos

46

En 1994 el Standish Group hizo un estudio sobre 350

compaas y cerca de 8000 proyectos de software para
averiguar como les estaba yendo. Los resultados fueron
desencantadores:

El 31% de los proyectos de software fueron cancelados antes de

tiempo (2480 proyectos)

En las grandes compaas, solo el 9% de los proyectos fue entregado

a termino de tiempo y dentro del costo que se presupuestaron; el 16%
consigui la satisfaccin de los requerimientos en las compaas
pequeas.

Importancia de los Requerimientos

47

En 1995 Standish pidi a los participantes que

especificarn las causas. Los resultados fueron los
siguientes:

Requerimientos incompletos (13,1%).

Falta de compromiso del usuario (12,4%).

Falta de recursos (10,6%).

Expectativas no realistas (9,9%).

Falta de soporte ejecutivo (9,3%).

Requerimientos y especificaciones cambiantes (8,7%).

Falta de planeamiento (8,1%).

Fin de la necesidad del sistema (7,5%).

Clasificacin de Requerimientos

Segn el TIPO los requerimientos se

clasifican en:
Requerimientos Funcionales
Requerimientos No Funcionales

48

Clasificacin de Requerimientos
REQUERIMIENTOS FUNCIONALES

49

Describen la funcionalidad o los servicios que se espera que el sistema

proveer.

Dependen del tipo de software, del sistema que se desarrollo y de los

posibles usuarios.

Cuando se expresan como Requerimientos del usuarios, se definen de

forma general.

Cuando se expresan como requerimiento del sistema describen con

detalle la funcin de ste, sus entradas y salidas, excepciones, etc

Clasificacin de Requerimientos
REQUERIMIENTOS NO FUNCIONALES

50

Son los requerimientos que no se refieren directamente a

las funciones especficas que entrega el sistema , sino a las
propiedades emergentes de ste, como la fiabilidad, la respuesta en el
tiempo y la capacidad de almacenamiento.

Muchos requerimientos no funcionales se refieren al sistema como un

todo ms que a rasgos particulares del mismo.

A menudo son mas crticos que los funcionales. Mientras que un

incumplimiento de un requerimiento funcional degrada el sistema, el
de un requerimiento no funcional del sistema lo inutiliza

Clasificacin de Requerimientos
REQUERIMIENTOS NO FUNCIONALES

Los requerimientos no funcionales se clasifican segn su implicancia:

Del producto : especifican comportamiento del producto. Ej.: de

desempeo en la rapidez de ejecucin del sistema, cuanta memoria se
requiere; los de fiabilidad que fijan la tasa de fallas para el sistema sea
aceptable, los de portabilidad y de usabilidad.

Organizacionales: se derivan de las polticas y procedimientos

existentes en la organizacin del cliente y del desarrollador.

Ej.: estndares en los procesos que deben utilizarse, mtodo de diseo

a utilizar.

51

Clasificacin de Requerimientos
REQUERIMIENTOS NO FUNCIONALES

Externo : cubre todos los requerimientos que se derivan de los factores

externos al sistema y de su proceso de desarrollo. Ej. Requerimientos de
interoperabilidad, requerimientos legales, requerimientos ticos.

Un problema comn con los requerimientos no funcionales es que

algunas veces son difciles de verificar.

De forma ideal los requerimientos no funcionales se deben expresar de

manera cuantitativa utilizando mtricas que se puedan probar de forma
objetiva. En la prctica, es difcil. El costo es muy alto.

52

Caractersticas de los Requerimientos

53

Es importante sealar que los requerimientos pueden servir

a tres propsitos:
Permitir que el desarrollador explique como ha entendido
lo que el cliente pretende del sistema.
Indican a los diseadores que funcionalidades y
caractersticas va a tener el sistema resultante.
Los requerimientos indican al equipo de pruebas que
demostraciones llevar a cabo para convencer al cliente
de que el sistema que se le entrega es de hecho lo que
haba ordenado.

Caractersticas de los Requerimientos

54

Los requerimientos deben ser de alta calidad para la buena

comprensin de clientes y desarrolladores.
Con este fin debe comprobarse que los requerimientos
posean las caractersticas que se desprenden de las
siguientes preguntas:
los requerimientos son correctos?. Cliente y
desarrollador deben revisarlos para asegurarse que no
tienen errores.
los requerimientos son consistentes?. Es decir, los
requerimientos planteados son no conflictivos ni ambiguos?.
Dos requerimientos son inconsistentes cuando es imposible
satisfacerlos simultneamente.

Caractersticas de los Requerimientos

los requerimientos son completos?. El conjunto de

requerimientos es completo si todos los estados posibles, cambios de
estado, entradas, productos, restricciones estn descritos en alguno de
los requerimientos.

los requerimientos son realistas? .El sistema puede hacer

realmente lo que el cliente esta pidiendo que haga?. Todos los
requerimientos deben ser revisados para asegurarse que son posibles.

describe cada requerimiento algo que es necesario para

el cliente? Los requerimientos deben ser revisados para conservar slo
aquellos que inciden directamente en la resolucin del problema del
cliente.

los requerimientos son verificables?. Debemos preparar

pruebas que demuestren que se han cumplido los requerimientos.

55

UML
Introduccin al UML

56

El UML ( Lenguaje Unificado de Modelado) es una herramienta de

desarrollo de software que permite generar diseos que capturen sus
ideas en una forma convencional y fcil de comprender que
comunicarlas a otras personas.

HP Confidential

UML
Por qu es necesario el UML

Anteriormente los programadores no realizaban anlisis muy profundo

sobre el problema a resolver. Esto en la actualidad es inapropiado en
los negocios de alto riesgo.

Hoy en da, es necesario con un plan bien analizado. El cliente y el

equipo tienen que comprender la solucin final del problema.

La clave est en organizar el proceso de diseo de tal forma que los

analistas, clientes, desarrolladores y otras personas involucradas en el
desarrollo de sistema lo comprendan y convengan con el. El UML.
Proporciona tal organizacin.

Un arquitecto no podra crear una estructura compleja como un edificio,

as mismo un ingeniera de software no podra crear un software sin un
anlisis y un diseo del mismo.

57

HP Confidential

UML
La concepcin del UML

58

El UML es la creacin de Grady Booch, James Rumbaugh e Ivar

Jacobson. Apodados Los tres amigos trabajaban en distintas empresas
en las decada de los 90, tenan su propios modelos y se juntaron
cuando empezaron trabajar en la empresa Rational Software
Corporation, en donde intercambiarn idas entre s y decidieron
desarrollar su trabajo en conjunto.

HP Confidential

Diagramas del UML

El UML esta computo por diversos elementos grficos que se combinan

para conformar diagramas.

Debido a que el UML es un lenguaje, cuenta con reglas para combinar

tales elementos.

La finalidad de los diagramas es presentar diversas perspectivas de un

sistema, a las cuales se les conoce como modelo.

Un modelo UML describe lo que supuestamente har un sistema, pero

no dice cmo implementar dicho sistema.

59

HP Confidential

Diagramas del UML

60

Los Diagramas en UML son:

Diagrama de clases

Diagrama de Objetos

Diagrama de Casos de Uso

Diagrama de Estados

Diagrama de Secuencias

Diagrama de Actividades

Diagrama de colaboraciones

Diagrama de Componentes

HP Confidential

Diagramas del UML

Diagrama de Clases:

Clase: es una categora o grupo de cosas que tienen atributos y

acciones similares.

Ejemplo:

61

Clase : Lavadora:

Atributos: marca, modelo, numero de serie y la capacidad

Acciones: agregar ropa, agregar detergente, activase y sacar ropa

HP Confidential

Diagramas del UML

Diagrama de Objetos:

Un objeto es una instancia de clase (una entidad que tiene valores

especificados de los atributos y acciones).

Ejemplo:

62

Clase: Lavadora:

Marca : LG

Modelo: WashMaster

Capacidad: 7K

HP Confidential

Instancia de Clase

Diagramas del UML

Diagrama de Casos de Uso:

Cubre principalmente el comportamiento del

sistema(servicios visibles externamente)
Se utiliza para:

63

Modelar el contexto de un sistema. Se especifican los actores y se

delimita el sistema.

Modelar los requisitos de un sistema. Qu debera hacer el sistema

desde un punto de vista externo, independientemente de cmo lo
haga.

HP Confidential

Diagramas del UML

Diagrama de Casos de Uso:

Un caso de uso es una descripcin de las acciones de un sistema desde

el punto de vista del usuario.

Ejemplo:

Actor: Usuario de la Lavadora

Caso de Uso: Lavar Ropa

64

HP Confidential

Diagramas del UML

Diagrama de Casos de Uso:

Realizar llamada
telefnica
Red
telefnica

Usuario

Recibir llamada
telefnica

extend

Realizar llamada
de conferencia

extend

Recibir llamada
adicional

Usar
Agenda
Telfono mvil

65

HP Confidential

Diagramas del UML

Diagrama de Secuencias:

Los diagramas de clases y los objetos representan informacin esttica.

No obstante en un sistema funcional los objetos interactan entre s, y
tales iteraciones suceden con el tiempo.

El diagrama de secuencia muestra la mecnica de la interaccin con

base en tiempo.

Componentes de una Lavadora:

66

Manguera de agua

Tambor

Sistema de drenaje

HP Confidential

Diagramas del UML

67

Diagrama de Secuencias:
Cual sera la secuencia del ejemplo lavadora:
1.

El agua empezara a llenar el tambor mediante una manguera

2.

El tambor permanecer inactivo durante cinco minutos

3.

La manguera dejar de abastecer agua

4.

El tambor girar de un lado a otro durante quince minutos

5.

El agua jabonosa saldra por el drenaje

6.

Comenzar nuevamente el abastecimiento de agua

7.

El tambor continuar girando

8.

El abastecimiento de agua se detendr

9.

El agua del enjuague saldr por el drenaje

10.

El tambor girar en una sola direccin y se incrementar su velocidad por cinco

minutos

11.

El tambor dejar de girar y el proceso de lavado habr finalizado.

HP Confidential

Diagramas del UML

Diagrama de Secuencias:

La figura presenta un diagrama

de secuencias que captura las
interacciones que se realizan a
travs del tiempo entre el
abastecimiento del agua, el
tambor y el drenaje. En este
diagrama el tiempo se da de
arriaba hacia abajo.

68

HP Confidential

Diagramas del UML

Diagrama de Actividades:

Las actividades que ocurren dentro de un caso de uso o dentro del

comportamiento de un objeto se dan, normalmente, en secuencia, como
en los 11 pasos del ejemplo anterior. En este ejemplo se muestra el
diagrama de actividades que representa los pasos del 4 al 6 de tal
secuencia.

69

HP Confidential

Diagramas del UML

Diagrama de Colaboracin:

Los elementos de un sistema trabajan en conjunto para cumplir con los

objetivos del sistema, y un lenguaje de modelado deber contar con
una forma de representar esto.

70

HP Confidential

Diagramas del UML

Diagrama de Componentes:

Se utiliza para modelar aspectos fsicos.

Vista de implementacin esttica.
Cosas fsicas: ejecutables, bibliotecas, tablas, archivos y
documentos.
Sirve para:

71

Modelar cdigo fuente.

Modelar versiones ejecutables.

Modelar bases de datos fsicas.

Modelar sistemas adaptables.

HP Confidential

Diagramas del UML

Diagrama de Componentes:
Modelado de una base de datos fsica

Universidad.db

curso

departamento

profesor

clase

estudiante

Diagramas del UML

Diagrama de Componentes:

Modelado de una versin ejecutable

trayectoria.dll

colision.dll

motor.dll
IMotor

IAutoTest
73

HP Confidential

Diagramas del UML

Diagrama de Despliegue:

El diagrama de despliegue muestra el diseo fsico de la red(network) y

el lugar donde residirn los componentes.

Muestra la configuracin fsica del sistema.

El diagrama de despliegue es usado por el PM, Arquitecto y personal e

despliegue para entender el diseo fsico del sistema y el lugar donde
residirn los subsistemas.

Se utilizan para:

74

Modelar sistemas empotrados.

Modelar sistemas cliente/servidor.

Modelar sistemas completamente distribuidos.

HP Confidential

Diagramas del UML

Diagrama de Despliegue:
Internet

clientes

servidores
Consola A

Consola B

75

HP Confidential

2..*

4..*

<<procesador>>
servidor cache

<<procesador>>
servidor

Despliega
http.exe
rting.exe

Despliega
admin.exe
logexc.exe

Paquetes y Subsistemas
Mecanismo de propsito
general para organizar
elementos en grupos
Contiene elementos por
composicin

Paquete1
+ Clase1
- Clase2

Paquete2
+ Clase3
- Clase4

76

HP Confidential