Utilização de DFDD e Redes de Petri para Comércio Eletrônico

•

ITESM

Todo para Aprender

31/10/2022

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Anatomía I

133.762 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

Este lli:ro at:e ser Ó:!\AEl.to,
a mT1s tar:cbr ai la 121.tina
fe:ia sella'.h. Sl retax:i. n
mis alli! de la fedla de
varimiemo, lo h:lc2 ac:ree-
cbr: a las rrul.ta3 g.e fija el de M o 11 t e r r e y
reglatelto. O,Ml'USE,"Í:ÁDODEM.UICO
Fecha de devolución
r R ~ ~ ' .. '
, l 1' 1'1Ai l.. \,.• ... _. 1
h:-·t: .. ,
, .\:·r i
Fecha de entrega
'
\~, sq~
13 MAR 2003
INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
de Monterrey
CAMPl'S ClER:\AVACA
Utilización del DFDD y Redes de Petri
para la especificación y simulación de
Sistemas de Comercio Electrónico .
Israel Sánchez Ramos
Sometido al Programa de Graduados en Informática y Computación en
cumplimiento parcial con los requerimientos para obtener el grado de:
Maestría en Administración de las Tecnologías de Información
Asesor
Dr. Juan Frausto Salís
Cuernavaca, Morelos
Enero 2003
. /
Utilización del DFDD y Redes de Petri para la especificación
y simulación de Sistemas de Comercio Electrónico
Presentada por:
ISRAEL SÁNCHEZ RAMOS
Aprobada por:
rausto Solís
Profesor Investiga r ITESM Campus Cuemavaca
í\sesor de Tesis
Dr. Francisco José Ca argo Saotacruz
Director de lnfonnática ITESM Campus Estado de México
Revisor de Tesis
rbaro Ferro Castro
Profesor de Ciencias Computacionales ITESM Campus Ciudad de México
Revisor de Tesis
A Dios,
que me ha dado más de lo que merezco.
A mis Padres,
quienes han hecho de mi todo lo que soy
y a quienes debo todo ...
A ti Maki que eres lo mejor que me ha pasado, gracias por todo
lo que me has permitido vivir a tu lado ... TE AMO
A Alfredo, Fernando, Héctor y Arturo a quienes considero
familia, gracias por mantenerme con los pies en la tie"a y por
enseñarme el verdadero significado de la palabra "amigo" ...
Los quiero y extraño, espero que la vida no nos pueda separar.
A mi hermana Miriam, para quien he tratado de ser un buen
ejemplo y pocas veces lo logro ...
A Antonio y Arturo Sánchez, que son lo más parecido a un
hermano que la vida me ha dado ...
A Rau/, Gise/y, Ismael, Ne/son, Melissa y Mayra,
quienes me han soportado este último año y medio ...
A Nancy, quien siempre me ha brindado su apoyo a pesar de la
distancia ...
Al Dr. Frausto quien nunca me negó su apoyo desde el momento
en que lo conocí...
A todos los que he conocido a lo largo de mi vida estudiantil y
que me han hecho una mejor persona, que por razones de
espacio no me es posible mencionarlos ...
A todos Uds. GRACIAS ...
g<@iltllndo el mtl/ll/ffi de eAtd ~,
Je haee h ~ (',MI, h 1(U} wdamá, e«:ÍÁI,(}, • • H
El comercio electrónico aprovecha la tecnología de Internet para llevar a cabo el
intercambio de bienes y servicios; y con el crecimiento exponencial que ha sufrido el
uso de la World Wide Web las transacciones en línea se han convertido en algo
necesario para que las empresas sean competitivas en el nuevo milenio. El problema
que se tiene es que por ser una tecnología de reciente creación la Ingeniería de
Software existente ofrece diversas metodologías para especificar sistemas de comercio
electrónico, pero ninguna totalmente adecuada.
Una buena especificación de un sistema de comercio electrónico, como de
cualquier otro tipo de sistema, es primordial porque de no contar con ella se pueden
generar gastos innecesarios al momento de dar mantenimiento al sistema y/o durante
el proceso de desarrollo, con la obvia consecuencia de pérdida de tiempo y dinero.
El modelo desarrollado a lo largo de éste trabajo, nombrado como CPN-DFDD,
sirve para especificar sistemas de comercio electrónico de manera que la relación
costo/beneficio sea la más adecuada, pues se utiliza el Diagrama de Flujo de Datos
Distribuido para modelar una vista general del sistema, mientras que con Redes de
Petri de Color se modelan las partes criticas del sistema.
Además de esto, aprovechando las facilidades que brindan las herramientas
computacionales de las Redes de Petri, se simulan las partes del sistema modeladas
con CPN, ya que si bien simular en la práctica nunca puede ser suficiente para probar
la exactitud de un sistema, si es una de las mejores aproximaciones que se pueden
tener.
Capítulo 1: Introducción .................................•..................................... 1
1.1 Antecedentes .................................................................................................... 2
1.2 Planteamiento del problema ........................................................................... 3
1.3 Objetivos de la tesis ....................................................................................... 4
1.4 Alcances y limitaciones ................................................................................... 4
1.5 Estvuctura de la tesis ..................................................................................... 5
Capítulo 2: Sistemas de comercio electrónico ...................................... 7
2.1 El comercio electrónico .................................................................................. 8
La evolución del comercio electrónico
La tienda virtual
2.2 Las empresas y el comercio electrónico ...................................................... 12
Implicaciones estratégicas del comercio electrónico
El diseño de sistemas de comercio electrónico
El comercio electrónico y la Ingeniería de Software
2.3 Sistemas de comercio electrónico ............................................................... 14
El comportamiento de los Sistemas de Comercio Electrónico
• Implicaciones del comportamiento de los sistemas de comercio electrónico
Capítulo 3: Métodos de especificación para comercio electrónico ••••• 17
3.1 El proceso de Ingeniería de Software ......................................................... 18
Análisis de requerimientos: el primer paso
Modelado
Modelación de paradigmas
Especificación
3.2 Métodos de especificación ............................................................................ 24
[)eficiencias de los métodos informales
,Por qué usar los métodos formales?
El problema con el Comercio Electrónico
Concepto de ·sistema•
3.3 Diagramas de Flujo de Datos ........................................................................ 28
Creación de modelos con t>Ft>'s
Análisis del método
3.4 Diagramas de Flujo de Datos Distribuido ................................................... 30
Análisis del método
3.5 Lenguaje Lotos ................................................................................................ 31
Especificación de sistemas con Lotos
Proceso de diseño de sistemas con Lotos
Análisis del método
3.6 Lenguaje de Modelado Unificado (UML) ..................................................... 33
Modelación de la parte dinámica del sistema
Análisis del método
3.7 Redes de Petri ................................................................................................. 36
Definición
Modelado de Sistemas con Redes de Petri
Ventajas y beneficios de utilizar Redes de Petri
Diferencia de las Redes de Petri y los demás métodos al modelar el
comportamiento dinámico
3.8 Elección de un método para modelar sistemas de e-commerce ............... 40
Capítulo 4: Diagrama de Flujo de Datos Distribuido .......................... 43
4.1 Diagrama de Flujo de Datos ........................................................................... 44
Definición
Elementos notacionales del DFD
Niveles del DFD
La ambigüedad en el DFD
Normas sintácticas del DFD
Convenciones para la denominación de componentes de un DFD
Reglas de construcción del DFD
Ventajas y desventajas del DFD
4.2 Diagrama de Flujo de Datos eXtendido ....................................................... 52
Reglas de construcción del DFDX
4.3 Diagrama de Flujo de Datos Distribuido ..................................................... 55
Lógica Temporal de Allen
Ejemplos de especificaciones con DFDD
Ejemplos de Aplicacióndel Algoritmo de Propagación
Reglas de construcción de los DFDD
Capítulo 5: Redes de Petri .................................................................... 63
5.1 Red de Petri ...................................................................................................... 64
Estructura de una red de Petri
Representación gráfica
Marcas de las Redes de Petri
Ejecución de una Red de Petri
Ejemplo del comportamiento de una Red de Petri
Tipos de ejecuciones con Redes de Petri
5.2 Redes de Petri de Color ................................................................................. 72
Redes de Petri de Color y Redes Blanco y Negro
El conjunto Color
Partes de una CPN
~,
'.~··
~--;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;¡¡¡¡;¡¡;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;;¡¡;¡;¡¡;;.l.nd_i_ce
Representación gráfica de las CPN
Definición Formal de las CPN
Ejecución de las CPN
Recomendaciones para modelar sistemas con CPN
Recomendaciones para graficar Modelos de Redes de Petri
Capítulo 6; Especificación del caso base con DFDD ............................ 83
6.1 Tienda virtual ................................................................................................... 84
6.2 Introducción a la especificación del caso base .......................................... 84
Alcance del sistema
6.3 Descripción del sistema ................................................................................. 86
Interfaces de hardware
Interfaces de software
Características del usuario
Limitaciones
6.4 Requerimientos de funcionamiento del caso base ...................................... 89
Desple.gar menú
Buscar/Navegar a través de los artículos
El proceso ºSistema de procesamiento de pedidos•
Consultar Estado de pedido
Agregar Registros del Cliente
Realizar compra
Proceso Cobros
Procesamiento del pedido
6.5 Conclusiones acerca de la especificación con DFDD ................................. 100
Capítulo 7: Especificación de las partes criticas del caso base con CPN .... 102
7.1 Introducción ..................................................................................................... 103
7.2 Vista General de la especificación con CPN ................................................ 103
7.3 El punto de partida ......................................................................................... 106
7.4 Solicitar Estado de Pedido ............................................................................ 107
7.5 Ingresar datos de compra y búsqueda de cliente ...................................... 107
7.6 Consulta de existencias en inventario .......................................................... 109
7.7 Solicitud de autorizacion de crédito al Banco ............................................ 110
7.8 I\Jegación de crédito ....................................................................................... 111
7.9 Procesamiento final del pedido ..................................................................... 112
7.10 Conclusiones acerca de la especificación con CPN ................................... 114
Capítulo 8: Design/CPN y simulación de las partes criticas del caso base .115
8.1 Introducción ..................................................................................................... 116
8.2 Design/CPN ...................................................................................................... 116
Interfaz principal de Design/CPN
Tipos de objetos en Design/CPN
Representación gráfica
Restricciones de sintaxis
8.3 Menús de Design/CPN .................................................................................... 119
8.4 Lenguaje CPN ML ............................................................................................ 121
Declaración del conjunto color
Funciones
Variables
Constantes
Verificación de sintaxis
8.5 La herramienta de simulación de Design/CPN ............................................ 125
Relación entre el editor y el simulador
Tipos de simulaciones
8.6 El proceso de simulación como ventaja competitiva en la especificación de
software ............................................................................................................ 126
• Ventajas
Desventajas
8.7 Consideraciones para simular las partes críticas del caso base .............. 128
8.8 Simulación del Sistema de Procesamiento de Pedidos .............................. 129
Ejemplo de simulación de un paso seleccionado arbitrariamente
Capítulo 9: Conclusiones y trabajo futuro ........................................... 134
9.1 Conclusiones ...................................................................................................... 135
9.2 Trabajo Futuro ................................................................................................ 136
Bibliografia ............................................................................................ 137
Apéndice A-Tabla de Transitividad de Allen .................................... 141
Apéndice B - Multiconjuntos ............................................................... 143
Lista de Figuras ..................................................................................... 147
'
• .. ·~¡
J;¿
"La Ingeniería de Software no ofrece una metodología especialmente diseñada
para sistemas de comercio electrónico ya que es una tecnología de reciente
creación ... "
$. _ -----------------------------------------------· __ r r_, t,_~a_d_u_cc-io_· n
1.1 ANTECEDENTES
El comercio electrónico aprovecha la tecnología de Internet para llevar a cabo
el intercambio de bienes y servicios; y con el crecimiento exponencial que ha sufrido el
uso de la Worl~ Wide Web las transacciones en línea se han convertido en algo
necesario para que las empresas sean competitivas en el nuevo milenio.
El problema que se tiene es que por ser una tecnología de reciente creación la
Ingeniería de Software existente ofrece diversas metodologías para especificar
sistemas de comercio electrónico, pero ninguna totalmente adecuada.
Una buena especificación de un sistema de comercio electrónico, como de
cualquier otro tipo de sistema, es primordial porque de no contar con ella se pueden
generar gastos innecesarios al momento de dar mantenimiento al sistema y/o durante
el proceso de desarrollo, con la obvia consecuencia de pérdida de tiempo y dinero.
Las 'Redes de Petri han destacado como una manera simple y poderosa para
especificar sistemas, pues al estar enfocadas tanto a estados como a acciones, el
usuario puede determinar libremente si en un momento determinado se enfoca en
especial a alguno de ellos.
Otra herramienta adecuada para la especificación de requerimientos es el
DFDD (Diagrama de Flujo de Datos Distribuido) debido a la facilidad de uso y a la
intuitividad intrínseca que presenta. Gracias a estas características fue elegido como
base para realizar la fusión entre las características formales e informales, esto es,
aprovechar las características de los lenguajes formales para dejar a un lado la
ambigüedad, pero sin dejar de tener la sencillez de comprensión y comunicación de los
lenguajes informales [Torres01].
La simulación es otra parte esencial del desarrollo de sistemas, pues con ella se
pueden anticipar errores en tiempo de ejecución y probar los sistemas en un medio
controlado para medir su respuesta a ciertas situaciones que se pudieran presentar;
...•
-¡:, o
~~: 1. Introducción
~¡ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.
ahorrándose con esto los costos excesivos que pudieragenerar un mal sistema una vez
que se ha implantado.
1.2 PLANTEÁMIENTO DEL PROBLEMA
Los sistemas de comercio electrónico muestran una serie de características
que requieren un modelado o representación especial, las principales son [Torres01]:
) Son sistemas altamente interactivos y sujetos a las decisiones de
elección del usuario.
) Son sistemas donde la duración de los procesos se da en intervalos y no
como puntos fijos de tiempo. Estos aspectos temporales pueden variar
desde la certeza de las relaciones entre los procesos, hasta la
· incertidumbre del orden de ocurrencia de eventos y la duración de los
mismos.
) Son sistemas altamente concurrentes.
Aunado a esto, los sistemas de comercio electrónico son un área de reciente
creación y aún no existe suficiente investigación en éste campo, lo que provoca que no
exista una metodología que se ajuste de manera adecuada a los sistemas basados en
Internet.
Con todo esto surge la problemática de encontrar un método eficiente para
especificar sistemas de comercio electrónico, pues se necesitan especificar procesos
donde se involucre el tiempo, manejar una gran cantidad de estos procesos
ejecutándose concurrentemente y además de ser un método sencillo de entender. Para
conseguir estas características tan especiales se requiere de la combinación de
diversos métodos existentes; por un lado se tienen las Redes de Petri Coloreadas que
son especialmente útiles para especificar sistemas concurrentes; mientras que por
otra parte se tiene a los Diagramas de Flujo de Datos que por su sencillez de
-..
• ¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡1¡¡¡¡¡¡. -I n-t-ro-d-u-cc-io¡¡¡¡¡' n
comprensión y la intuitividad de su uso han sido muy utilizados para especificar
sistemas computacionales, sin embargo, resulta muy tediosa su aplicación cuando se
especifican sistemas complejos, como son los que conllevan concurrencia.
1.3 OBJETIVOS DE LA TESIS
Los objetivos que pretende alcanzar la elaboración de esta tesis dada la
problemática planteada son:
1. Desarrollar un modelo de especificación para sistemas de comercio
electrónico utilizando Redes de Petri de Color y Diagramas de Flujo de
Datos Distribuido.
2. Especificar con el modelo desarrollado un caso de estudio de un sistema
de comercio electrónico, identificar sus partes críticas y modelarlas con
Redes de Petri de Color.
1.4 ALCANCES Y LIMITACIONES
1.4.1 Alcances
) Analizar distintos métodos de especificación para comercio electrónico
y mostrar sus principales ventajas y desventajas.
> Mostrar las características principales de los Diagramas de Flujo de
Datos Distribuido.
> Mostrar las características principales de las Redes de Petri de Color.
) Mostrar las características principales del programa Design/CPN y del
lenguaje CPN-ML.
'•
:, f
~·¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡1¡¡¡¡. -l n-t-ro-d-u-cc-,o-· n
) Simular con Redes de Petri las partes críticas identificadas del caso
base y verificar si la ejecución es adecuada.
) Encontrar una manera correcta de realizar especificaciones de
requerimientos formales haciendo uso de Redes de Petri de Color y
Di,agramas de Flujo de Datos en sistemas de comercio electrónico.
1.4.2 Limitaciones
) No se desarrollará un asistente computacional para el modelo de
especificación desarrollado, de manera que su implantación será manual.
) Se utilizará el lenguaje CPN-ML para representar y simular las partes
del modelo de especificación desarrolladas con Redes de Petri.
1.5 ESTRUCTURA DE LA TESIS
Los primeros cinco capítulos podrían ubicarse como el marco teórico de la tesis.
En el Capítulo 2 se describen las características que hacen de los Sistemas de
Comercio Electrónico tan difíciles de especificar y el por qué la mayoría de las
empresas desean implementarlos.
El Capítulo 3 ubica a la especificación y el modelado dentro del proceso de
Ingeniería de Software, además de que se realiza un análisis de diversos métodos de
especificación de sistemas mostrando las ventajas y desventajas de cada uno.
Los Capítulos 4 y 5 muestran las características principales del Diagrama de
Flujo de Datos Distribuido y las Redes de Petri respectivamente.
En el Capítulo 6 se especifica el caso base utilizando el Diagrama de Flujo de
Datos Distribuido y se identifican las partes críticas del sistema que se especificarán
con Redes de Petri de Color a lo largo del Capítulo 7.
·., ,i ________ ¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡l _. r_n_tr_o_d u_c_c,¡¡¡¡¡¡¡·ón
En el Capítulo 8 se hace una breve descripción del programa Design/CPN
versión 2.0 que se utiliza para simular la ejecución de Redes de Petri, además de que
se muestran los resultados de simular las partes críticas del caso base.
El Capítulo 9 presenta las conclusiones que se obtuvieron y el trabajo futuro
que se puede g~erar a partir de ésta tesis.
El Apéndice A muestra la Tabla de Transitividad de Allen, necesaria para el
análisis de consistencia temporal del DFDD. El Apéndice B lista las principales
características y propiedades de los multiconjuntos, sin los cuales no es posible
entender las Redes de Petri.
Al final del presente trabajo se muestra la bibliografía consultada para
realizar esta tesis.
6
"El comercio electrónico es un potente químico socioeconómico que reacciona
con cualquier cosa que lo toca" - Raví Ka/a/cota.
8 ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ ... ¡¡¡¡¡¡1 ·-5-' s-t-er.-:-. '-ª-s -'J-e -C-º-m-e-rc-1 o¡¡¡¡¡¡¡¡¡¡El-e-ct-ro-' n-ic_o
2.1 EL COMERCIO ELECTRÓNICO*
Internet ha resultado ser el fenómeno social y económico más importante a
partir de la segunda mitad de la década de los 90's. Dentro de los mercados
financieros abundan historias de éxitos fenomenales de inversiones realizadas en un
solo día, nadamás porque una empresa anexó.coma su modelo comercial; se han dado
casos de compañías cuyas acciones duplicaron su valor en un día cuando se anunció que
se iba a crear su división de Internet [CohanOO].
Son muchos los factores que han influido para que se den dichos fenómenos,
dentro de éstos destaca el hecho de que actualmente alrededor de 300 millones de
personas en todo el mundo hacen uso de Internet, lo cual demuestra el enorme
potencial que esta red ha alcanzado [Pérez01].
Int~rnet tiene muchos usos pero sin lugar a dudas el que más destaca es el
comercio electrónico o e-commerce (definido como el intercambio de bienes y
servicios a través de Internet) cuyo crecimiento ha sido exponencial, principalmente
porque permite a las empresas ser más eficientes y más flexibles en sus operaciones
internas, trabajar más estrechamente con sus suministradores, dar mejor respuesta a
las necesidades y expectativas de sus clientes debido a que es un canal de
comunicación de dos vías, pero sobre todo: se tiene acceso a un mercado global
[Avalos01] [CohanOO]. Es tanto el impacto del comercio electrónico que Ravi Kalakota
lo define como ·un potente químico socioeconómico que reacciona con cualquier cosa
que lo toca•[Kalakota01].
El comercio electrónico incorpora •todas las transacciones de valor que
involucren la transferencia de información, productos, servicios o pagos por medio de
redes electrónicas• [CohanOO]. El comercio electrónico se refiere generalmentea
todas las formas de transacciones relacionadas con las actividades comerciales (hacer
• En el presente trabajo se utiliza ·comercio electrónico• y ·e-commerce" como sinónimos.
2 . .5,stemas de Comercio Electrónico cíli.-t: 1fYJ9· ¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
negocios electrónicamente), incluyendo organizaciones e individuos, que están basadas
en el proceso y transmisión de datos digitalizados, como son texto, sonido e imagen".
Esto involucra muchas actividades diversas, dentro de las que destacan: negociación
electrónica de bienes y servicios, envío de componentes digitales en línea,
transferencia electrónica de fondos, negociación de segmentos electrónicos,
conocimientos de embarque electrónicos, acciones comerciales, diseño e ingeniería
cooperativa, fuentes en línea, compras, mercadeo directo al consumidor y servicio de
post-venta.
2.1.1 La evolución del comercio electrónico
La forma de hacer negocios de forma virtual está cambiando a los negocios
físicos y tangibles a los que el cliente y empresa estaban acostumbrados hace unos
años, pues. las empresas ven a los negocios en línea como una oportunidad -para
destacar, obteniendo así mayor presencia en el mercado y por lo tanto mayores
ganancias económicas [Avalos01]. La perspectiva de hacer negocios de manera virtual
también entusiasma a los medios de comunicación y a los políticos. Por un lado el
comercio electrónico despierta tal interés en los medios de información que los
reportajes sobre el tema aparecen en los noticiarios y dentro de las primeras planas
todos los días. Por su parte los políticos consideran que el comercio electrónico es una
manera de generar empleos y probables ingresos fiscales (esto porque el e-commerce
estimula el crecimiento de la economía, al tiempo que mantiene la inflación en niveles
bajos) [CohanOO].
Pero a pesar del nivel alcanzado actualmente por el comercio electrónico su
impacto ha ocurrido en fases [Kalakota01]. En su primera fase (1994-1997), el e-
commerce estaba a punto de despegar: asegurándose de que todos tuvieran un sitio
Web, encontrando la demanda para cada compañía (grande o pequeña) y haciendo que
éstas tuvieran al menos ·algo" en Internet. Las personas no estaban seguras de qué
estaban haciendo, pero sabían que debían tener una presencia en línea.
$¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2¡¡¡¡¡¡.¡¡¡¡¡¡S¡¡¡¡¡¡,s¡¡¡¡¡¡t¡¡¡¡¡¡em¡¡¡¡¡¡¡¡a¡¡¡¡¡¡s -d-e -C-º-m-e-rc-,o¡¡¡¡¡¡¡¡El-e-ct-ro-· n-ic_o
La segunda fase (1997-2000) del comercio electrónico fue acerca de las
ªtransaccionesH (comprar y vender sobre medios digitales). El enfoque de esta fase
fue en los flujos y ganancias totales, por ejemplo: el hacer coincidir a compradores y
vendedores que nunca se hubieran encontrado en el pasado. Algunas veces se trató
sólo de realizar transacciones que se hubieran podido hacer a través del comercio
tradicional (por órdenes de compra en papel) y decir que ese negocio se hizo en
Internet, aunque el significado de ese cambio haya sido casi trivial. En esta fase los
anuncios eran acerca de obtener un mayor flujo a toda costa.
Hoy en día el comercio electrónico está entrando en su tercera fase (2000-l?)
con un enfoque en cómo Internet puede impactar la rentabilidad, y dicha rentabilidad
no es acerca de incrementar las ganancias brutas sino de incrementar los márgenes
totales. Algunos autores llaman a esta fase ·e-business" e incluye todas las
aplicaciones y procesos que permiten a una empresa brindar una transacción comercial.
Así el com~rcio electrónico se ha convertido en una estrategia total que redefine los
viejos modelos de negocios (con la suma de la tecnología) para maximizar el valor del
cliente y las ganancias.
2.1.2 La tienda virtual
El comercio electrónico es un término genérico para describir la manera en que
las organizaciones negocian electrónicamente. Usa un grupo de tecnologías para
comunicarse con clientes u otras compañías, para llevar a cabo investigación o
búsqueda de información o para conducir transacciones mercantiles. En todo caso el
Internet es el más conocido de ellos, otros incluyen intranets, intercambio electrónico
de datos y tarjetas inteligentes.
Para ubicar al comercio electrónico se debe primero ubicar a los tres
componentes del mercado: agentes, productos y procesos; dichos elementos pueden
ser físicos o virtuales dentro de ésta modalidad de intercambio de bienes. Las ocho
combinaciones posibles de agentes físicos o virtuales, productos y procesos, permiten
,,,
.,
~t' 8 ;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2¡¡¡¡¡¡. -5-,s-t-em¡¡¡¡¡¡¡¡¡¡¡as¡¡¡¡¡¡¡¡¡¡¡d¡¡¡¡¡¡e¡¡¡¡¡¡C¡¡¡¡¡¡o¡¡¡¡¡¡m¡¡¡¡¡¡e¡¡¡¡¡¡rc-'-º-E-/e-c-tr-ó-n,;;.·co
la identificación de áreas de comercio tradicional, así como áreas principales donde
todos los tipos de servicios y procesos comerciales tienen el potencial de convertirse
en productos digitales intercambiados en una red digital. En la Tabla 2.1 se muestran
éstas posibles combinaciones.
El tipo de comercio electrónico que más ha proliferado entre las empresas (y
sobre el cual se enfocará el presente trabajo) es el que incluye agentes físicos que
venden un producto de manera virtual o digital, lo que normalmente es conocido como
ªtienda virtuales• y se clasifica como B2C (Business to consumer) [Kalakota01]. Este
canal de venta ofrece virtualmente todo tipo de productos, desde libros, discos
compactos, artículos de oficina, boletos de avión, etc.
AGENTE
ompradores, (c
V
int
endedores,
ermediarios)
Físico
Físico
Físico
Físico
Digital
Digital
Digital
Digital
'
!
i
i
!
1
i
'
i
1
!
i
i
1
1
1
1
1
1
1
' i
!
PRODUCTO PROCESO
i EJEMPLO DE TIPO DE (bienes (interacción
intercambiados) entre agentes) 1 COMERCIO
1
Físico
1
Físico
1
Comercio tradicional
Físico
1
Digital 1
Ventas en línea para productos
1
físicos (Tiendas virtuales)
Digital
1
Físico I Venta de productos digitales en stock .
1
Digital
1
Digital 1 Venta en línea y despacho de
1
productos digitales
Físico
1
Físico
1
Piso de intercambio de bienes
1
!
Piso de intercambio de stock Digital Físico 1
1 !
1
l
Físico Digital
1
Oferta en línea de productos físicos
1
Principio de comercio electrónico:
Digital Digital
intercambio de productos digitales en
una base electrónica con
1 interacciones electrónicas.
Tabla 2.1 - Componentes físicos y digitales del comercio
11
·• -'"' t
- ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2¡¡¡¡¡¡¡. -5-' s-te-m-ª-s-"'-deiiiiiiiiiiiC-om-, -er-c-,o-E-1-ec-t-ro-· n-ic-o
Dentro del B2C una transacción típica de comercio electrónico abarca tres
pasos generales [CohanOO]:
1. Una persona utiliza el Web para recopilar información que le ayude a
decidir qué producto o servicio comprar.
2. La persona transmite por Web la información de pago (usualmente el
número de su tarjeta de crédito) al vendedor.
3. El vendedor procesa la información de pago y entrega el producto o
servicio al cliente.
Cabe mencionar que el comercio electrónico tiene un valor agregado no siempre
visible, que beneficia tanto a las empresas como a los consumidores. Por un lado las
tiendas virtuales proporcionan a los clientes un vasto mundode información, la cual
permite comparar precios, productos y/o servicios. Por su parte las empresas por cada
transacción realizada pueden convertir la información en conocimiento, pues obtienen
datos importantes como el perfil del cliente y sus preferencias de compra, lo que les
puede ayudar a mejorar sus relaciones con los compradores (CRM) [AvalosOl].
Dentro de la modalidad de B2C, se encuentran los negocios puramente virtuales
de las llamadas empresas .COM, es decir las compañías que nacieron en Internet y no
tienen presencia física en el mundo real (por ejemplo Amazon). Además existen
negocios reales que crean sitios Web como otro punto de venta.
2.2 LAS EMPRESAS Y EL COMERCIO ELECTRÓNICO
Ante todas las ventajas competitivas que el comercio electrónico puede brindar
a la organización, las empresas no pueden rezagarse y se han dedicado a la
implantación de sistemas de e-commerce como parte integral de su estrategia; sin
embargo, el que la implementación de dichos sistemas llegue a un término exitoso no
es cosa fácil pues son muchos los factores involucrados.
12
2. Sistemas de Comercio Electrónico ~,.~if.i
~~ ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;¡¡¡
Contrario a lo que se pudiera pensar, el desarrollo y utilización de las
aplicaciones de Internet se ha ganado la reputación de ser rápido y no atado a los
sistemas y las metodologías. Desafortunadamente, como las herramientas y los
requerimientos impuestos en dichos sistemas de comercio electrónico se han vuelto
más complejos, el alcance del proyecto y el presupuesto se han disparado
dramáticamente. Las necesidades de un sitio de comercio electrónico cruza múltiples
límites departamentales (de ventas a marketing, a legal, a entregas, a manejo del
producto y finanzas) y todos esos grupos necesitan ser partícipes en el proyecto de e-
commerce [Ayers02].
2.2.1 Implicaciones estratégicas del comercio electrónico
Desde el punto de vista estratégico se debe tomar en cuenta que una idea de
negocio como es el comercio electrónico, respaldada por el uso imaginativo de la
tecnología,· solamente funcionará si se tienen las herramientas y una infraestructura
para operarlas. La introducción al comercio electrónico necesita de nuevas
herramientas y con toda probabilidad, alternativas para el modo de hacer negocios. La
organización necesita estar segura de que puede realizar los cambios con éxito a los
nuevos canales de ventas y también que su administración y capacidad de producción
pueden responder a tiempo a las demandas de un canal electrónico de ventas
[Avalos01].
2.2.2 El diseño de sistemas de comercio electrónico
Diseñar las aplicaciones que van a ·dar la cara" al cliente en vez de diseñar
aplicaciones internas sigue siendo nuevo para la mayoría de las organizaciones. No sólo
la interfaz necesita ser funcional, también se necesita que sea visualmente atractiva.
El cliente virtual, ya sea 828 o 82C, sólo visitará repetidamente el sitio Web por un
número limitado de razones [Ayers02]:
¡.i. El cliente virtual ahorra tiempo
13
2. Sistemas de Comercio Electrónico ~, ... ;, .;.·;·
~ <· ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
" .
,. El cliente virtual ahorra dinero
) Los productos y servicios sólo están disponibles vía Web.
) Comparación de compras.
Un reporte reciente del ªUSA TodaY- menciona que el 60% de las
transacciones de compra son abandonadas antes de presionar el botón de compra. Las
principales razones citadas incluyen: precio incorrecto, falta de ofertas especiales, no
existen preguntas de servicio al cliente y en general: incertidumbre. Duramente esto
es el estándar que acarrean los errores de software (bugs) y las tecnologías que
ofrecen un lento desempeño [Ayers02].
2.2.3 El comercio electrónico y la Ingeniería de Software
Aunado a todo lo anterior, los sistemas de comercio electrónico presentan un
comportamjento muy especial que la Ingeniería de Software no ha podido cubrir
totalmente. En la siguiente sección se muestra una descripción de dicha
comportamiento.
2.3 SISTEMAS DE COMERCIO ELECTRÓNICO
Los sistemas de comercio electrónico muestran una serie de características
que requieren una especificación y un modelado o representación ªespecial• por ser
sistemas altamente interactivos, concurrentes y sujetos a las decisiones de elección
del usuario. En otras palabras, son sistemas donde la duración de los procesos se da en
intervalos y no como puntos fijos de tiempo (y además, varios usuarios pueden
encontrarse ejecutando el mismo proceso). Estos aspectos temporales pueden variar
desde la certeza de las relaciones entre los procesos, hasta la incertidumbre del
orden de ocurrencia de eventos y la duración de los mismos [TorresOl].
,~
s· ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2¡¡¡¡. -S-i s-t e¡¡¡¡m¡¡¡¡a¡¡¡¡s¡¡¡¡d¡¡¡¡e¡¡¡¡¡¡¡C¡¡¡¡o m-, -e r-c-1 o-E-1-ec-t-ro-· n-i e-o
Aunado a todo lo mencionado anteriormente, al ser el comercio electrónico una
tecnología de reciente creación la Ingeniería de Software existente no ofrece un
método de especificación creado solamente para sistemas de este tipo, tan sólo se
tienen diversas aproximaciones pero no destacándose una en particular, ninguna que
compense la relación costo/beneficio. Este punto es crítico, pues una buena
especificación de un sistema de comercio electrónico, como de cualquier otro
software, es primordial porque si no se realiza de manera adecuada se pueden generar
gastos innecesarios al momento de la implantación o durante el mantenimiento al
sistema, dándose incluso casos extremos en los que se debe desechar todo el trabajo
avanzado con la obvia consecuencia de pérdida de tiempo y dinero.
2.3.1 El comportamiento de los Sistemas de comercio electrónico [TorresOt]
En sistemas de comercio electrónico a los usuarios les toma diferentes lapsos
de tiempo ejecutar alguna actividad, sin que el sistema lo pueda controlar o
determinar. Para un sistema de e-commerce no es posible conocer o definir cuánto
tiempo durará comprando un usuario determinado y cuanto tiempo otro, cada uno tiene
necesidades diferentes y en base a esa necesidad o hábitos de interactuar con el
sistema será la forma en que el cliente se mueva dentro de él C-navegue•), por tal
motivo, no es posible especificarla como un punto fijo de tiempo.
Tampoco se puede especificar cuánto tiempo le tomará al sistema responder
sobre una actividad o acción que ha ejecutado el usuario, esto porque se encuentra
inmerso en una red sujeta a características físicas (como el tipo de hardware del
equipo que se utiliza), características de transmisión (tráfico de red, velocidad de la
red), etc. generando con ello una imprecisión en la especificación temporal de los
sistemas.
i .'
~¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2 •. _s_¡s_te_m_a_s_d_e_C_o_m_,e_~_ci_o_E_/e_ct_r_ón_ic¡¡¡¡¡¡o
2.3.2 Implicaciones del comportamiento de los sistemas de comercio
electrónico
Ante el funcionamiento en base a eventos y reacciones del usuario de los
sistemas de comercio electrónico, son pocos los métodos de especificación que
permiten denotar éste comportamiento y la mayoría de ellos no resultan ser
adecuados para la mayoría de las organizaciones debido al alto costo que representa el
capacitara los ingenieros de software en el difícil uso de dichos métodos. En el
siguiente capítulo se analizan varios métodos de especificación que soportan el diseño
de sistemas de comercio electrónico, de manera que se pueda encontrar el más
adecuado con respecto al costo/beneficio.
16
lil . . __ ..
~de~~
cgMJle/}'eÚJ Y5~teo
"Ante el funcionamiento en base a eventos y reacciones del usuario de los
sistemas de comercio electrónico, son pocos lo métodos de especificación que
permiten denotar éste tipo de comportamiento ... "
8¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡3¡¡¡¡¡. -"'-' e-· to¡¡¡¡¡d¡¡¡¡¡o¡¡¡¡¡s¡¡¡¡¡d¡¡¡¡¡e¡¡¡¡¡e¡¡¡¡¡sp-e-c-1 fi-c ª-c-1 º-n-p-ª-r-a -co¡¡¡¡¡m¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡e r-º-º-e-1 e-c-tr¡¡¡¡¡ó¡¡¡¡¡m¡¡¡¡¡¡¡¡¡co
3.1 EL PROCESO DE INGENIERÍA DE SOF1WARE
El papel global del software en un sistema para una empresa es identificado
durante la fase del análisis, pero es necesario considerar una visión lo más profunda
posible del papel de dicho software para poder comprender los requerimientos
específicos que deben ser considerados en la construcción de un sistema de alta
calidad. El análisis es importante porque si no se realiza de manera adecuada es
posible que se cree una solución ªelegante• que resuelva incorrectamente el problema.
El resultado de éste mal análisis es tiempo y dinero perdido, tal vez frustración
personal y seguramente un cliente descontento y quizás perdido [Pressman02].
El análisis y la especificación de los requerimientos a simple vista parece una
tarea relativamente sencilla, sin embargo en este caso las apariencias engañan.
3.1.1 Análisis de requerimientos: el primer paso
El análisis de los requerimientos es una tarea de la ingeniería de software que
cubre el hueco entre la definición del software a nivel sistema y el diseño del
software. El análisis de requerimientos permite al ingeniero de sistemas especificar
las características operacionales del software (función, datos y rendimientos), indica
la interfaz del software con otros elementos del sistema y establece las restricciones
que debe cumplir el software.
El análisis de requerimientos del software puede dividirse en cinco áreas de
esfuerzo [Pressman02]:
1. Reconocimiento del problema
2. Evaluación y síntesis
3. Modelado
4. Especificación
5. Revisión
IS
~· ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡J¡¡¡¡., ._rv_,_é c_c_d_o s_· _; ,=, ___ =_s r:_· ~_e_: fi_, c_ac_,_º n_. _P_ª_r a_c._·-o_m_" e_r_c,_· o_e_l e_c_tr_o_· n_i c_o
Ingeniería de
sistemas de
Figura 3.1 El análisis como puente entre la ingeniería y el diseño de software [Pressman021
.
La evaluación del problema y la síntesis de solución son el · área principal de
esfuerzo en el análisis, pero antes de que los requerimientos puedan ser analizados,
modelados o especificados deben ser recogidos a través de un proceso de obtención.
La técnica de obtención de requerimientos más usada es llevar a cabo una reunión o
entrevista preliminar, donde el cliente debe dejar en claro lo que desea del sistema a
desarrollar, y el analista debe tratar de reunir toda la información posible que pueda
llegar a requerir del cliente.
El gran problema de esta etapa es que los clientes y los ingenieros de software
a menudo tienen una mentalidad inconsciente de ·nosotros y ellos•, así que en vez de
trabajar como un equipo para identificar y refinar los requerimientos, cada uno trata
de definir su •territorio• y la comunicación que se obtiene con este obstáculo no es la
adecuada, resultando en un análisis inconcluso o tal vez hasta inadecuado.
Esta deficiencia en la comunicación debe ser resuelta, pues de no ser así las
pérdidas de tiempo y dinero pueden resultar estratosféricas, pues entre más se tarde
dentro del proceso de ingeniería de software en identificar un problema o tal vez un
... ... ,
$¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡3¡¡¡¡. _M_é_to_d_o_s _d_e _e_sp_e_c_1 fi_c_ac_1 º-· n¡¡¡¡¡¡¡¡¡¡.oa_r_a_c_o_m_e_rc_¡ o¡¡¡¡¡¡¡¡¡¡et_e_ct_ro_· n_i e-o
mal análisis, las pérdidas crecerán casi exponencialmente, como se puede notar en la
Tabla 3.1.
ETAPA COSTO DE REPARACIÓN
Requerimientos 1-2
Diseño 5
Codificación 10
Pruebas de Módulo 20
Pruebas de Sistema 50
• Mantenimiento 100 -200 ,,
Tabla 3.1 Costo de reparación de un mal análisis dentro del proceso de software
Las recomendaciones que da [Pressman02] para una buena ingeniería de
requerimientos son las siguientes:
) Entender el problema antes de empezar a crear el modelo de análisis
) Registrar el origen y la razón de cada requerimiento
) Usar múltiples planteamientos de requerimientos
) Dar prioridad a los requerimientos.
) Trabajar para eliminar la ambigüedad.
3.1.2 Modelado
Los modelos se crean para entender mejor la entidad que se va a construir,
cuando la entidad es algo físico se puede construir un modelo idéntico en forma pero a
una escala más pequeña. Sin embargo, cuando la entidad que se va a construir es
software, el modelo debe tener una forma diferente, y ésta es una de las áreas
críticas de la ingeniería de software, pues el modelo debe de ser capaz de modelar la
información que transforma el software, las funciones (y subfunciones) que permiten
'
:,
D, .
S'¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡J¡¡¡¡¡. -'..,'-¿ t-º-d-o s¡¡¡¡¡¡¡¡dP---es¡¡¡¡¡p¡¡¡¡¡e¡¡¡¡¡e,¡¡¡¡¡· ft-cª-c-: º-n-, º-ª-r-a -e-o m-·-e-rc-1 º-e-1-ec-t-ro-· n-1 e-o
que ocurran las transformaciones y el comportamiento del sistema cuando ocurren
estas transformaciones.
El segundo y tercer pr1nc1p1os operativos del análisis requieren de la
construcción de modelos, que se pueden dividir en modelos de función y modelos de
comportamiento [Pressman02]:
~ Modelos funcionales: El software transforma la información y para
hacerlo debe realizar al menos tres funciones genéricas: entrada,
procesamiento y salida. Cuando se crean modelos funcionales de una
aplicación, el ingeniero de software se concentra en funciones
específicas del problema.
~ Modelos de comportamiento: La mayoría del software responde a
los acontecimientos del mundo exterior, ésta característica
estímulo-respuesta forma la base del modelo del comportamiento.
Los modelos creados dentro del análisis de requerimientos desempeñan papeles
muy importantes, entre los que se encuentran [Pressman02]:
~ El modelo ayuda al analista a entender la información, la función y el
comportamiento del sistema, haciendo por tanto más fácil y
sistemática la tarea de análisis de requerimientos.
~ El modelo se convierte en el punto de mira para la revisión y por
tanto la clave para determinar si se ha completado, su consistencia y
la precisión de la especificación.
~ El modelo se convierte en el fundamento para el diseño,
proporcionando al diseñador una representación esencial del
software que pueda trasladarse al contexto de la implementación.
21
..
1J' lf ;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡J¡¡¡¡¡. -',.,'-é-to-d-O'.:>---deiiiiiiiiiie-sp-e-c_, fi_ca_c_: o_n_; ·-ºª_r_a_c_o_rr_. e_rc_:o¡¡¡¡¡¡¡¡¡¡e,_·e-ct-ro_· n-ic-o
3.1.3 Modelación de Paradigmas [Meta93]
Con el propósito de crear el modelo de un sistema se necesitan varias maneras
de representar los componentes de los que consiste. Estas representaciones no
necesitan tener una similitud detallada a los componentes de un sistema real, lo que se
necesita es un· conjunto de abstracciones que permitan capturar la esencia de
cualquier sistema que se desee modelar. Este conjunto de abstracciones es
frecuentemente llamado Modelador de Paradigmas.
No existe un Modelador de Paradigmas que sea el más eficiente en todoslo
casos. La elección del paradigma a usar depende en la naturaleza del sistema modelado
y en el objetivo del modelo. Para los sistemas como el clima por ejemplo, donde no hay
un flujo de información y sólo hay una sucesión de estados, se usan los sistemas de
ecuaciones diferenciales parciales. Para modelar objetos físicos, como por ejemplo los
componentes de una máquina, los mejores métodos son CAD/CAM.
Con frecuencia, los humanos diseñan sistemas que realizan labores complejas
distribuidas en espacio y tiempo y que enwelven un flujo discreto de objetos y/o
información. Los sistemas sociales donde vive la gente también son de ésta naturaleza.
Sistemas como éstos pueden ser mejorados modelándolos.
Cuando se quiere modelar únicamente la estructura de un sistema el modelo de
paradigma de más utilidad es el estático. Cuando se quiere modelar la estructura y el
comportamiento de un sistema, entonces el modelo más necesario es el dinámico.
3.1.4 Especificación
Una de las principales afirmaciones que se pueden hacer dentro de la etapa de
definición de requerimientos de la Ingeniería de Software es la de que el modo de
especificación tiene mucho que ver con la calidad de la solución. A lo largo de los años
los ingenieros de software se han visto forzados a trabajar con especificaciones
incompletas, inconsistentes o engañosas provocando con esto confusión, y como
..,..,
ú,
~,¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡]¡¡¡¡;¡. -'"'-é-to-d-o s-· -d ,::,----=s-p-e-c.-· fr-cª-c-: º-n-p-ª-,-,-ª -c-om¡¡¡¡¡¡¡¡e¡¡¡¡;¡rc-' º-e-1-ec-t-ro-· n-i e-o
resultado de esto la calidad, el alcance y la fecha de entrega son los que sufren las
consecuencias [Pressman02].
La especificación, independientemente de cómo se realice, puede verse como un
proceso de representación. Los requerimientos se representan de manera que como
fin último lleven· al éxito de la implementación del software. En el libro de Pressman se
proponen los siguientes principios de especificación [Pressman02]:
1. Separar la funcionalidad de la implementación
2. Desarrollar un modelo del comportamiento deseado de un sistema
que comprenda datos y las respuestas funcionales de un sistema a
varios estímulos del entorno.
3. Establecer el contexto en que opera el software especificando la
manera en la que otros componentes del sistema interactúan con él.
4. Definir el entorno en que va a operar el sistema.
5. Crear un modelo intuitivo en vez de un diseño o modelo de
implementación.
6. Reconocer que • ta especificación debe ser tolerante a un posible
crecimiento si no es completa~ Una especificación es siempre un
modelo (una abstracción) de alguna situación real o prevista que
normalmente suele ser compleja. De ahí que será incompleta y
existirá a muchos niveles de detalle.
7. Establecer el contenido y la estructura de una especificación de
manera que acepte cambios.
El software puede especificarse de varias maneras; sin embargo, para que los
requerimientos se puedan mostrar en papel o en un medio electrónico, es útil seguir
estas directrices [Pressman02]:
~ El formato de la representación y el contenido deben estar
relacionados con el problema .
., ' __ ,
$, ¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡J¡¡¡¡¡. '-'Vf-é t-º-d-osiiiiiiiiiiideiiiiiiiiiii.=s-p-e-c.-· t:_cª-c-,·º-n-1--na-r-a -e-o m¡¡¡¡¡¡¡¡¡¡¡e r-c-' º-e-1-ec-t-ro-· n-ic-o
>- La información contenida dentro de la especificación debe estar
escalonada.
>- Los diagramas y otras formas de notación deben restringirse en
número y ser consistentes en su empleo.
) · Las representaciones deben permitir revisiones.
Mucho se ha investigado acerca del mejor método de especificación y lo que se
ha podido descubrir es que la elección está basada en las preferencias individuales de
los ingenieros de software (esta familiaridad es resultado de la disposición espacial,
formas fácilmente reconocibles o el grado de formalidad), siendo esto un obstáculo
para la calidad, pues no siempre el método de preferencia es el más adecuado para un
sistema determinado.
Es así como la elección de un método de especificación debe estar
fundamentada de acuerdo a lo que se requiera representar, pero también debe de
tener la suficiente facilidad de aprendizaje de manera que no se obtenga un
presupuesto demasiado alto. Este balance resulta bastante difícil de obtener, sobre
todo al momento de especificar sistemas complejos (como es el caso del comercio
electrónico, que cuenta con operaciones concurrentes).
3.2 MÉTODOS DE ESPECIFICACIÓN
Los métodos de especificación pueden dividirse en dos grandes tipos: los
métodos formales y los métodos informales; este espectro de formalidad va unido al
grado de rigor matemático que se aplica durante los métodos de análisis y diseño.
Las propiedades que se desean de una especificación formal (carencia de
ambigüedad, consistencia y completitud) son los objetivos de todos los métodos de
especificación (formales e informales); sin embargo, la utilización de métodos
..,,
··>.,{· o:;¡;;¡¡¡¡;;;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡. ]. ,"fétodos de espeoficaCJón para comeroo electrónico
formales da lugar a una probabilidad mucho mayor de alcanzar estos objetivos ideales.
Pero a pesar de las ventajas obvias que brinda el uso de los métodos formales a la
ingeniería de software su aplicación está muy discutida, pues mientras sus impulsores
afirman que puede revolucionar el desarrollo del software sus detractores piensan que
resultan imposiblemente difíciles. Lo cierto es que en sistemas críticos como son los
de seguridad, un fallo puede pagarse muy caro (pues en estos sistemas una falla de
computadora puede resultar en pérdidas humanas), por eso en estas situaciones es
esencial descubrir los errores antes de poner en operación la computadora. Los
métodos formales reducen drásticamente los errores de especificación y en
consecuencia son la base del software de calidad.
[Pressman98] define los métodos formales de la siguiente forma:
Los métodos formales que se utilizan para desarrollar sistemas de
computadoras son técnicas de base matemática para describir las propiedades
· del sistema. Estos métodos formales proporcionan marcos de referencia en el
seno de los cuales las personas pueden especificar, desarrollar y verificar los
sistemas de manera sistemática, en lugar de hacerlo ad hoc.
Se dice que un método es formal si posee una base matemática estable, que
normalmente vendrá dada por un lenguaje formal de especificación. Esta base
proporciona una forma de definir de manera precisa nociones tales como la
consistencia y la completitud y, lo que resulta mucho más relevante, la
especificación, la implementación y la correccion.
3.2.1 Deficiencias de los métodos informales
Los métodos informales para el análisis y diseño de sistemas hacen un amplio
uso del lenguaje natural y de toda una gama de notaciones gráficas. Aún cuando la
aplicación cuidadosa de los métodos de análisis y diseño junto con una revisión
detallada puede llevar a un software de calidad, la torpeza en la aplicación de estos
métodos puede crear toda una gama de problemas. La especificación informal de un
sistema puede contener las siguientes deficiencias [Pressman98]:
..., -
"\
..
4C,l'
. -·, :i,.- 3. ;vfétodos de espeoficac;én para comercio electrónico 'S"'·· ... ,. ..
F ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.) Contradicciones: conjuntos de sentencias que se pueden interpretar
de formas opuestas.
) Ambigüedades: sentencias que se pueden interpretar de muchas
maneras
) · Vaguedades y sentencias incompletas: se dan porque alcanzar un
nivel de precisión de forma consistente es una tarea casi imposible
) Niveles mezclados de abstracción: se producen cuando sentencias
abstractas se mezclan aleatoriamente con sentencias que se
encuentran en un nivel muy inferior.
Todos estos problemas se producen de manera frecuente y cada uno de ellos
representa una deficiencia potencial en los métodos convencionales o informales.
3.2.2 ¿Po,;- qué usar los métodos formales?
Si se desea tener un software de calidad lo cierto es que se debe adoptar el
uso de los métodos formales (a pesar de su costo), pues aunque un error del sistema
no cueste vidas humanas si puede costar horas-hombre o pérdidas económicas para la
empresa, pues una mala especificación de software resulta en un mal sistema y por lo
tanto en dinero mal invertido.
Sin embargo, adoptar un método formal no resulta fácil pues resulta caro para
la empresa, pero si se ve esto como una inversión para obtener software de calidad y
como una forma para eliminar las ambigüedades y de obtener un mayor rigor en las
primeras fases del proceso de ingeniería de software, el gasto se justifica y
seguramente resultará en un mayor retorno de la inversión, pues de no usarlos, tal vez
se tenga que revisar la especificación en múltiples ocasiones, haciendo que los costos
se disparen y que la fecha de entrega se retrase.
Por estas razones es necesario encontrar el balance ideal: un método de
especificación formal que resulte fácil de aprender (con lo que la capacitación del
....
_()
•t ;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡3¡¡¡¡¡¡. '-'"'-é e-· º-d-o s¡¡¡¡¡¡¡¡¡¡.Je¡¡¡¡¡¡¡¡¡¡es-p-e-c.-f:-ca-c-1 º-· n-, P-ª-r-a -c-om-, -er-c-1 º-e-1-ec-t-ra-· n-ic-o
<;Jf!
personal resultará barata), pero que a la vez tenga el poder necesario para especificar
el sistema de manera correcta.
3.2.3 El problema con el Comercio Electrónico
,
Los sistemas de comercio electrónico son sistemas altamente concurrentes, es
decir, se ejecutan una serie de procesos al mismo tiempo (y frecuentemente con un
grado elevado de comunicación entre estos procesos). El principal problema de las
especificaciones formales e informales es que algunas de ellas no tienen las funciones
para especificar este tipo de sistemas, y a pesar de que se han realizado muchos
esfuerzos para modificar algunas notaciones para acompañar la concurrencia, no se ha
logrado mucho éxito ya que no se diseñaron realmente con esta idea.
Sin embargo algunos métodos de especificación si se diseñaron especialmente
para trata_r los sistemas concurrentes, pero algunos son bastante difíciles de
comprender y en consecuencia implican costos elevados para la empresa, por lo que
debe obtenerse un balance una vez más. Para encontrar éste punto de equilibrio en las
siguientes secciones del presente capítulo se analizarán diferentes métodos de
especificación, indicando sus ventajas y desventajas de cada uno, pero antes, para
poder entender los métodos de especificación de manera correcta, primero es
necesario entender el concepto de sistema.
3.2.4 Concepto de "Sistema"
La idea fundamental en un sistema es que se compone de módulos que
interactúan entre sí, los cuales pueden ser considerados por sí mismos un sistema y se
podría estudiar su comportamiento por separado y de esta manera aislarlos, pero
siempre teniendo en cuenta la interacción que guardan con los otros módulos.
Ahora que si se desea conocer en qué condiciones se encuentran los módulos, es
como si se detuviera al sistema en el tiempo, las condiciones internas de los módulos
determinarían el estado en el que se encuentran, para esto se entiende que un sistema
..,..,
- I
3. 1'-'~to1_ic:; Je ~s¡:;eoficaoón para comerco electrónico
es un arreglo dinámico que en el transcurso del tiempo tiene variaciones y no
permanece estático. El estado de un módulo con frecuencia depende de su historia, es
decir de las acciones dadas en un tiempo anterior.
Aquí saltan a la vista dos conceptos importantes: acciones y estados; las
acciones conducen a un estado determinado del módulo en el tiempo, las acciones de un
módulo en un sistema pueden ocurrir simultáneamente con las acciones de otros
módulos, dado que ellos interactúan entre sí, es necesario sincronizar los eventos.
Esto puede resultar en que las condiciones de un módulo en el tiempo necesitan como
entradas las salidas de otro, el cual necesita más tiempo para generar las salidas, es
entonces cuando se piensa en paralelismo y concurrencia.
Existen dos conceptos más que deben ser tomados en cuenta al momento de
analizar los sistemas: eventos y condiciones; los eventos son las acciones que se dan en
el sistema y llevan a un estado, se puede describir un estado como un conjunto de
condiciones (a menudo es útil representar dichas condiciones por medio de
predicados).
Para que cierto evento ocurra es necesario que ciertas condiciones se cumplan,
estas son llamadas pre-condiciones del evento, la ocurrencia del evento puede llevar a
otras condiciones y es entonces cuando se dan las post-condiciones.
3.3 DIAGRAMAS DE FLUJO DE DATOS
Los diagramas de flujo de datos (DFD) son una herramienta de especificación
que permite representar el sistema como una red de procesos funcionales conectados
unos con otros. El DFD es una de las herramientas de modelado más utilizada,
particularmente para sistemas en los cuales las funciones son de principal importancia
y más complejas que los datos que manipula el sistema.
$¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡;3¡¡¡¡¡¡. -~-' é-t º-d-o-s -d-e -·-=-SP¡¡¡¡¡¡e¡¡¡¡¡¡o¡¡¡¡¡¡fi¡¡¡¡¡¡ca¡¡¡¡¡¡c¡¡¡¡¡¡, º-· n-p-a-ra¡¡¡¡¡¡¡¡¡¡;co¡¡¡¡¡¡m¡¡¡¡¡¡e¡¡¡¡¡¡r¡¡¡¡¡¡o¡¡¡¡¡¡o -e-1 e-c-tr-ón-i-co
Esta es una herramienta gráfica que describe el flujo de los datos a través del
sistema. El diagrama muestra la transformación de datos de entrada en datos de
salida por medio de los procesos. En general, los Diagramas de Flujo de datos
muestran:
) De dónde vienen y hacia dónde van los datos cuando salen del sistema
(Entidades Externas)
) Cuáles son los datos que llegan y salen (Flujo de Datos)
) Dónde se almacenan los datos (Depósito de Datos)
) Qué procesos transforman los datos
) Las interacciones entre depósitos de datos y procesos.
3.3.1 Creación de modelos con DFD's
) Todos los componentes del gráfico participan en la actividad que se está
modelando, por lo tanto, en el DFD, cada uno de sus componentes debe
estar conectado por lo menos con otro componente.
) Cada proceso produce la información que el sistema necesita, por lo tanto,
en el DFD, cada proceso debe usar, al menos, un flujo de datos de entrada y
producir, al menos, un flujo de salida.
) El modelo del proceso identifica la fuente de todos los datos utiliz.ados en
el sistema, por lo tanto, cada elemento de datos en un flujo de salida debe
corresponder o derivarse de un elemento de datos de uno de los flujos de
entrada del proceso.
) Cada flujo de datos soporta, al menos, una actividad del sistema, por lo
tanto, en el DFD, cada flujo de datos, desde o hacia un almacenamiento de
datos o una entidad externa, debe conectarse a un proceso.
J. r·,rercdos t}e 2speoficaoón para comeroo electrómco •.. : ..... ·/;
~~-.;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
3.3.2 Análisis del método
El Diagrama deFlujo de Datos es un método que ha estado presente en la
ingeniería de software desde sus inicios, y si ha permanecido vigente es gracias a su
facilidad de uso y a su manejo casi intuitivo. Sin embargo, esto tiene su costo, pues al
ser un método d,e especificación informal está sujeto a ambigüedades (ver sección 4.1)
que pueden resultar en una mala especificación de software; aunado a esto, no
permiten ver el comportamiento dinámico del sistema.
3.4 DIAGRAMA DE FLUJO DE DATOS DISTRIBUIDO
La facilidad que brindan los diagramas de flujo de datos no puede pasar
desapercibida, así que con la finalidad de dar una base formal al DFD se crea el
Diagrama de Flujo de Datos Distribuido (DFDD ), el cual permite eliminar las
ambigüedades que se tienen con el DFD.
El Diagrama de Flujo de Datos Distribuido es un método formal ligero que
permite la especificación de sistemas concurrentes, presentando el mismo aspecto que
un método informal, por lo que no pierde las ventajas de aceptabilidad y bajo costo de
utilización.
A grandes rasgos, éste método lo que hace es proporcionar a cada proceso del
DFD con una relación temporal que permite ubicar su ejecución en el tiempo con
respecto de los demás procesos (relaciones como befare, after, meets, etc.); dichas
relaciones son tomadas de la lógica temporal de Allen {[Allen83]). Además a cada arco
del DFDD se le asocia un símbolo que permite representar si el dato es necesario o
deseable para la ejecución de un proceso; por último, si un proceso tiene como
entradas varios arcos éstos se pueden agrupar en conjuntos de AND y OR.
~·--iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii.J-. -M-ét_o_d_osiiiiiiiiiiiiiiidP ___ es_p_e_o_'fi-ca_c_io-·n_p_a_r_a_c_om¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡er_c_,o_e_1_ec_t_ro_'n_ic_o
3.4.1 Análisis del método
Este método es ideal para especificaciones de sistemas concurrentes, por lo
cual lo hace ideal para modelar sistemas de Comercio electrónico. La lógica temporal
de Allen es relativamente fácil de aprender y de aplicar en comparación con otros
métodos; sin em.bargo, éste método cuenta con la gran desventaja de que no es posible
observar el comportamiento dinámico del sistema.
3.5 LENGUAJE LOTOS
LOTOS es un lenguaje de especificación formal desarrollado por ISO. En
LOTOS un sistema se especifica mediante el ordenamiento temporal de las acciones
que constituyen su comportamiento observable externamente. LOTOS tiene dos
componentes fundamentales:
},>, Comportamiento e interacciones entre procesos (incluye elementos que
fueron introducidos en otras álgebras de procesos).
},>, Descripción de estructuras de datos y expresiones de valor ( esta parte
de LOTOS está basada en la teoría formal de tipos abstractos de
datos).
3.5.1 Especificación de sistemas con LOTOS
El punto de partida de LOTOS es que un sistema puede especificarse mediante
la definición de una relación temporal entre las interacciones que constituyen el
comportamiento observable del mismo.
LOTOS especifica un sistema mediante la composición de un conjunto de
procesos capaces de realizar acciones internas o de interactuar con otros procesos
que forman su entorno. Los procesos se comunican entre sí a través de puertas que
comunican a dichos procesos con otros procesos. Un proceso puede comunicarse, a
:, .
J 1"1étodos ,je -:SD-=C1ficac:cn pan comerc:s c=f.-:ct.--.-jn,co
través de una puerta, con uno o más procesos simultáneamente, de forma que la
comunicación es, en general, n-aria.
De esta forma, LOTOS sirve muy bien para la especificación de sistemas
distribuidos o sistemas concurrentes, para lo que aporta además toda su capacidad
formal a la hora de probar, mediante el paso automatizado de pruebas, que el sistema
es correcto.
3.5.2 Proceso de diseño de sistemas con LOTOS
LOTOS facilita el proceso de diseño mediante refinamientos sucesivos. Es
decir, el sistema se construye de forma incremental como una secuencia de pasos
dirigida a obtener un producto final que satisfaga los requerimientos expresados
inicialmente por el usuario o cliente. Un refinamiento supone una decisión de diseño, la
selección de una de las posibles soluciones que satisfacen los requerimientos del
usuario.
En este proceso de diseño, es importante disponer de un mecanismo que
permita asegurar que los efectos de una transformación sobre la especificación
original son únicamente los deseados. A este respecto, en el dominio operacional de
LOTOS es posible relacionar especificaciones mediante distintos tipos de
equivalencias o preórdenes. El tipo de equivalencia o preorden elegido dependerá del
tipo de transformación que se aplique.
Otra posibilidad es demostrar la corrección de la transformación asegurando
que el programa transformado satisface ciertas propiedades. La lógica temporal
proporciona un buen formalismo para la especificación de las propiedades de un
sistema, lo que la hace adecuada para este propósito. Con lógica temporal un sistema
queda completamente especificado al conocer el conjunto de propiedades (fórmulas de
dicha lógica) que satisface.
' ..,
·'-
::,,
3. Métodos de especificación para comemo electrónico
3.5.3 Análisis del método
Al ser un método formal algebraico el lenguaje Lotos es extremadamente
difícil de usar y requiere de sólidos conocimientos matemáticos y de lógica, por lo que
la capacitación en el uso de dicho lenguaje resultará además de tediosa, costosa para
la empresa. Comb ventaja innegable tiene que es un método que una vez que se domina,
no da lugar a ambigüedades y sirve muy bien para la especificación de sistemas
distribuidos o sistemas concurrentes, permitiendo probar la ªcorrectividad• del
sistema mediante pruebas automáticas.
3.6 LENGUAJE DE MODELADO UNIFICADO (UML)
El • Unified Modelling Languagé' o más conocido como UML es un lenguaje de
modelado 'visual utilizado para especificar, visualizar, construir y documentar
artefactos de un sistema de software. Captura decisiones y conocimiento sobre los
sistemas que se deben construir; ayuda a entender, diseñar, hojear, configurar,
mantener y desarrollar la información sobre tales sistemas. Está pensado para su
empleo con todos los métodos de desarrollo, etapas del ciclo de vida, dominios de la
aplicación y medios.
UML incluye conceptos semánticos, notación y pr1nc1p1os generales. Tiene
partes estáticas, dinámicas, de entorno y organizativas. La especificación de UML no
define un proceso estándar pero está pensado para ser útil en un proceso de
desarrollo iterativo.
UML capta la información sobre la estructura estática y el comportamiento
dinámico de un sistema. Un sistema se modela como una colección de objetos discretos
que interactúan para realizar un trabajo que finalmente beneficia a un usuario
externo. La estructura estática define los tipos de objetos importantes para un
sistema y para su implementación, así como las relaciones entre los objetos. El
~ '
·'-'
s¡¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡¡¡;;;¡¡¡¡¡¡¡¡]¡¡¡¡¡¡. iiiiii,..,,iiiiiieiiiiiir.:;¡¡¡¡¡¡d¡¡¡¡¡¡c¡¡¡¡¡¡s iiiiiidiiiiiieiiiiiieiiiiiispiiiiiieiiiiiiciiiiii;fiiiiiiiciiiiiiaciiiiiiioiiiiii' n-·-ºª-riiiiiiaiiiiiiciiiiiioiiiiiimiiiiiieiiiiiirc¡¡¡¡¡¡,o¡¡¡¡¡¡¡¡;;;¡¡e/iiiiiieiiiiiictiiiiiiroiiiiii· niiiiiiic_o
comportamiento dinámico define la historia de los objetos en el tiempo y la
comunicación entre objetos para cumplir sus objetivos. El modelar un sistema desde
varios puntos de vista, separados pero relacionados, permite entenderlo para
diferentes propósitos.
3.6.1 Modelación de la parte dinámica del sistema
Para modelar el comportamiento dinámico del sistema con UML se utilizan 3
componentes: la vista de actividades, la vista de la máquina de estados y la vista de
interacciones.
La vistade la máquina de estados describe el comportamiento dinámico de los
objetos, en un cierto plazo, modelando los ciclos de vida de los objetos de cada clase.
Cada objeto se trata como una entidad aislada que se comunica con el resto del mundo
detectando eventos y respondiendo a ellos. Los eventos representan las clases de
cambios que un objeto puede detectar: la recepción de llamadas o señales explícitas
desde un objeto a otro, un cambio en ciertos valores, o el paso del tiempo. Cualquier
cosa que pueda afectar a un objeto se puede caracterizar como evento, los sucesos
del mundo real se modelan como señales del mundo exterior al sistema [UMLOO].
Un grafo de actividades es una forma especial de máquina de estados, prevista
para modelar cómputos y flujo de trabajos. Los estados del grafo de actividades
representan los estados de ejecución del cómputo, no los estados de un objeto
ordinario. Normalmente, un grafo de actividades asume que los cómputos proceden sin
interrupciones externas por evento. Un grafo de actividades contiene estados de
actividad. Un estado de actividad representa la ejecución de una sentencia en un
procedimiento, o el funcionamiento de una actividad en un flujo de trabajo. En lugar
de esperar un evento, como en un estado de espera normal, un estado de actividad
espera la terminación de su cómputo. Cuando la actividad termina, entonces la
ejecución procede al siguiente estado de actividad dentro del grafo. Una transición de
terminación es activada en un diagrama de actividades cuando se completa la actividad
3. Métodos de espeC/ficaoón para comercio electrónico •. ('. ~!;/# ,¡;;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.
precedente. Los estados de actividad no tienen generalmente transiciones con eventos
explícitos, pero pueden ser abortados en estados que los incluyen. Un grafo de
actividades puede también contener estados de acción, que son similares a los estados
de actividad, excepto en que son atómicos y no permiten transiciones mientras están
activos [UMLOO].
Los objetos obran recíprocamente para implementar comportamiento, ésta
interacción se puede describir de dos maneras complementarias, una de ellas se
centra en los objetos individuales (diagrama de secuencia) y la otra en una colección
de objetos cooperantes (diagrama de colaboración) [UMLOO].
Una máquina de estados es una vista estrecha y profunda del comportamiento,
una vista de reduccionista que mira a cada objeto individualmente. Una especificación
de la máquina de estados es exacta y conduce inmediatamente al código. Sin embargo,
puede ser difícil entender el funcionamiento total de un sistema, debido a que una .
máquina de estados se centra en un solo objeto a la vez, y se deben combinar los
efectos de muchas máquinas de estados para determinar el comportamiento de todo
el sistema. La vista de interacción proporciona una visión más integral del
comportamiento de un sistema de objetos. Esta vista es modelada por colaboraciones
[UMLOO].
3.6.2 Análisis del método
UML se ha convertido rápidamente en una notación estándar para el modelado
de sistemas, esto porque abarca todos los aspectos de implementación, es orientado a
objetos, es relativamente fácil de aprender y sobre todo: toma en cuenta a los casos
de uso del negocio.
En cuanto a la dinámica del sistema, UML soporta su especificación pero no hay
manera de comprobarla pues el método no cuenta con simulación.
3. Métodos de especificaCión para comerC10 electrónico ~s· .. -··{
p _, .;¡¡¡¡¡¡¡¡;¡.;¡¡¡¡¡¡¡¡;¡.;¡¡¡¡¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.
t ;,
3.7 REDES DE PETRI
Las redes de Petri representan una alternativa para modelar sistemas, sus
características hacen que para algunos problemas las redes de Petri funcionen de una
manera natural. Las PN como usualmente se conocen a las redes de Petri (Petri Net)
fueron inventadas por el alemán Karl Adam Petri en 1962 y presentadas en su tesis
doctoral •Kommunikation mit automaten" (Comunicación con autómatas), donde
establece los fundamentos para el desarrollo teórico de los conceptos básicos de las
PN.
Las PN son consideradas como una herramienta para el estudio de los sistemas,
con su ayuda se puede modelar el comportamiento y la estructura de un sistema y
llevar el modelo a condiciones límite, que en un sistema real son difíciles de lograr o
muy costosas. Comparadas con otros modelos de comportamiento dinámico gráficos,
como los diagramas de las máquinas de estados finitos, las PN ofrecen una forma de
expresar procesos que requieren sincronía. Y quizás lo más importante es que las PN
pueden ser analizadas de manera formal y obtener información del comportamiento
dinámico del sistema modelado.
Una de las principales razones del éxito de las Redes de Petri es el hecho de
que simultáneamente se trabaja con tres elementos: teoría, herramientas y uso
práctico. Esto se puede apreciar en la Figura 3.2.
3.7.1 Definición
RED DE PETRI: Una técnica formal, gráfica y ejecutable para la especificación
y análisis de sistemas concurrentes y dinámicos de eventos discretos, que en
épocas recientes se ha establecido como un estándar.
FORMAL: La técnica está matemáticamente bien definida.
Muchas propiedades estáticas y dinámicas de una Red de Petri (y por lo
* ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡.J¡¡¡¡.., ·-rv-,e-· t-º-d-o s¡¡¡¡¡¡¡¡¡¡¡1P---e-sp-e-c-1 fi-' c-ac-1-0 niiiiiiiiiiip-ª,-,-ª-c-º-m-e-r-c.-10-e-l e-c-tr-º-· n-i'-º
tanto de un sistema especificado utilizando ésta técnica) pueden ser
matemáticamente demostradas.
HERRAMIENTAS
• Edición
• Simulación
• Verificación
TEORIA
• Modelos
• Conceptos básicos
• Métodos de verificación
USO PRÁCTICO
• Especificación
• Investigación
• Verificación
• Implementación
Figura 3.2 Elementos que contribuyen al éxito de las redes de Petri
GRAFICA: La técnica pertenece a un área de clasificación de las
matemáticas llamada •Teoría de Grafos", lo que hace que una red de
Petri pueda ser representada tanto gráfica como matemáticamente. La
habilidad de visualizar estructuras y comportamientos de una red de
Petri promueve el entendimiento del sistema modelado. Las
herramientas de software existentes soportan la construcción gráfica y
la visualización.
EJECUTABLE: Una red de Petri puede ser ejecutada y el
comportamiento dinámico será observado gráficamente. Las
herramientas de software que existen permiten una ejecución
automática.
,-
·'
...
'-',
(f. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡..¡¡¡¡;¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡J_. rv_r_é t_o_d_o s¡¡¡¡¡¡¡d e¡¡¡¡¡¡¡es_p_e_o_r;_c a_c_, º-· n_p_a_r_a _c_o m __ e_rc_, o_e_i_e c_t_ra_· n_i e-o
ESPECIFICACION: Los requerimientos del sistema expresados y
verificados (por análisis formal) usando la técnica constituyen un
sistema formal de especificación.
ANALISIS: La especificación del sistema es a menudo un
proceso iterativo con requerimientos que inicialmente son pobremente
sobreentendidos o mal definidos. Una especificación en la forma de un
modelo de red de Petri puede ser formalmente analizado contra los
requerimientos estáticos y dinámicos del sistema. La retroalimentación
visual del gráfico de la red de Petri en cada iteración de la
especificación incrementa el entendimiento de los requerimientos,
resalta los errores en el modelo (o algunas veces los requerimientos) y
resulta en una rápida convergencia en una especificación
matemáticamente correcta y consistente. Las herramientas