6.3 EDIFICACIÓN. [Proceso] Esta etapa comprende la construcción del sistema en una serie de iteraciones increméntales. La construcción de un sistema utilizando ciclos de desarrollo iterativos tiene ciertas ventajas, tales como:
• Disminuye la complejidad.
• Existe una realimentación casi inmediata ya que la implementación se da en seguida para un subconjunto del sistema. Este proceso se representar en la Figura # 5.
Figura # 8, Edificación.
Cada ciclo de desarrollo iterativo consta de las etapas que se muestran en la Figura # 7.
Figura # 9, Ciclo de Desarrollo iterativo.
1. Refinamiento de lo Planeado. Es el punto de conexión entre la etapa de Planeación y Elaboración y Edificación. Aquí debe existir un mayor entendimiento del problema, por lo que es posible hacer algunos ajustes antes de continuar.
2. Sincronización de artifacts. Si existe una iteración anterior, lo más común es que existe una diferencia entre el diseño de artifacts y el código generado, por lo que es necesario hacer ajustes para su concordancia. (Ajuste de documentación, diagramas, etc.).
3. El Análisis. Hace énfasis en encontrar y describir los objetos en el dominio del problema. 4. El Diseño. Hace énfasis en definir lógicamente objetos de software, los cuales serán
implementados en un lenguaje de programación orientado a objetos.
5. Construcción. Los componentes del diseño son implementados en algún lenguaje de programación.
6. La Prueba. Consiste en la verificación de partes y del sistema total. Edificación. Ciclo de Desarrollo 1 Ciclo de Desarrollo 2 Ciclo de Desarrollo . . . n
Ciclo de desarrollo iterativo.
1. Refinamiento de lo Planeado 2. Sincronización de Artifacts 3. Análisis
6.4 ANÁLISIS.
6.4.1 Construcción de un Modelo Conceptual.
Un Modelo conceptual: es una representación de conceptos en el dominio del problema.
La primer tarea en la etapa de análisis es identificar conceptos en el dominio del problema y documentarlos en un modelo conceptual. En esta etapa, se recomienda construir el Modelo Conceptual de todo el sistema.
Concepto: es una idea, cosa u objeto y puede ser considerado en términos de: • Símbolos: Palabras o imágenes que representan un concepto • Intención: Definición de un concepto
• Extensión: Conjunto de ejemplos que se aplican al concepto.
El modelo muestra conceptos, asociaciones entre conceptos y actividades de conceptos. Los conceptos pueden ser identificados mediante 2 estrategias:
• Usar una lista de categoría de conceptos.
• Identificar los conceptos mediante frases sustantivas. • Usar una lista de categoría de conceptos
Casos de Uso: Expandido y Esencial Diagrama de Caso de Uso Contratos Diagrama de Secuencia del Sistema Glosario Modelo Conceptual Diagrama de Estado
Se puede iniciar la construcción del modelo conceptual escribiendo una lista de conceptos candidatos utilizando la siguiente lista, la cual contiene categorías comunes que pueden ser consideradas en cualquier orden de acuerdo a su importancia.
CATEGORÍA DE CONCEPTO EJEMPLO
Diseño, o descripción de cosas Especificación del Producto
Lugares Vivero
Transacciones Venta, Pago
Rol de gente Vendedor, Cliente
Contenedores de otras cosas Vivero Cosas en un contenedor Plantas
Eventos Venta, consulta
Procesos Vender producto
Catálogos Catalogo de productos,
Catalogo de Clientes Instrumentos financieros y servicios. Línea de crédito.
Libros y manuales Manual de operación.
• Identificar los conceptos mediante frases sustantivas.
Esta es una técnica muy útil, se basa en la identificación de sustantivos y frases sustantivas de la descripción textual en el dominio del problema y tomarlos en cuenta ya sea como conceptos candidatos o como atributos. vea los conceptos y/o atributos en negrillas.
Curso de Eventos: Facturación Versión 1.
No Acción del Actor No Respuesta del Sistema
1. Este caso de uso inicia cuando el Cliente llega a la Terminal de Punto de Venta con los productos que desea adquirir. 2. Para cada artículo el vendedor introduce
la clave del producto.
3. Una vez introducida la clave del artículo se muestra su descripción y precio de lista
4. El vendedor teclea el número de artículos vendidos.
5. Se muestra el total del importe por artículo.
6. Una vez terminada la captura de todos los artículos. el vendedor indica que ha terminado.
7. Se despliega el total de la venta.
8. Se introduce el número de cliente. 9. Se despliegan los datos del cliente. 10. Se imprime la Factura.
Los Casos de Uso expandidos son una excelente fuente de información para el bosquejo de esta etapa de análisis.
Como hacer un modelo conceptual
1. Listar los conceptos candidatos usando las 2 estrategias mencionadas anteriormente 2. Dibujarlos en un modelo conceptual
3. Agregar asociaciones necesarias 4. Añadir atributos necesarios
Nombrando y modelando cosas.
También se puede emplear la estrategia que se sigue en la construcción de mapas: • Use los nombres que existen en el territorio. Se debe utilizar el vocabulario del dominio. • Excluya características irrelevantes. En el modelo conceptual se deben excluir conceptos
en el dominio del problema que no participan en los requerimientos.
• No agregue cosas que no existen. Se deberán excluir cosas que no existen en el dominio del problema bajo consideración.
Errores comunes en la identificación de conceptos.
Cuando se construye un modelo conceptual es común representar algunas cosas como si fueran atributos, cuando en realidad deben ser conceptos. Para prevenir este error se puede seguir la siguiente regla de dedo.
6.4.2 Modelo Conceptual para el Vivero “La Flor de Malva”. [Caso de Estudio] Tomando como guía los lineamientos expuestos, y considerando el sistema completo, se descubren los siguientes conceptos:
! Cliente. ! Vendedor.
! Terminal de Punto de Venta. ! Vivero.
! Producto, artículo. ! Catalogo de Productos. ! Especificación del producto. ! Catalogo de Clientes ! Datos del cliente. ! Almacén
! Factura. ! Venta.
Si el concepto X no es algo que se puede representar con un número o texto en el mundo real, X probablemente es un concepto, no un atributo.
Entonces, el modelo conceptual para el problema del Vivero se representa gráficamente de la siguiente manera:
6.4.3 Agregando asociaciones. [Proceso]
Una vez que han sido descubiertos los conceptos se procede a encontrar las asociaciones que hay entre ellos.
A continuación se presenta una línea guía para descubrir las asociaciones mediante una lista de categorías.
CATEGORIA SISTEMA del VIVERO
A es una parte física de B no aplicable A es una parte lógica de B Producto – Factura A esta físicamente contenido en B Almacén – Vivero
A esta lógicamente contenido en B Especificación del Producto-Catalogo de productos
A es una descripción para B Especificación del Producto – Producto A es un artículo de una transacción o
reporte de B
artículo - Venta
A es un miembro de B Punto de Venta - Vivero A es una subunidad organizacional de B no aplicable
A usa o maneja a B Vendedor – Terminal de Punto de Venta A se comunica con B Cliente – Vendedor (no aplicable) A esta relacionada a una transacción B Cliente - Venta
A es una transacción relacionada con una transacción de B
no aplicable
A es propiedad de B Artículo – Almacen
Tabla # 13, Guía para descubrir Asociaciones. Catalogo de Productos
Almacén
Venta Factura
Figura # 11, Conceptos del Sistema
Vivero Especificación del Producto
d Catalogo de Clientes Datos del Cliente
El modelo conceptual queda representado de la siguiente forma: [Caso de Estudio]
Es necesario hacer notar que Cliente ni Vendedor se incluyen en el modelo conceptual ya que éstos se manejaron como actores en los casos de uso.
6.4.4 Definiendo multiplicidad.
Se representa lo obvio de la multiplicidad, así por ejemplo.
! El Vivero tiene uno o mas Terminales de Puntos de Venta. ! El Vivero tiene un Almacén.
! El Vivero cuenta con un Catalogo de Clientes. ! El Almacén resguarda muchos artículos.
! El Almacén cuenta con un Catalogo de Productos.
! El Catalogo de productos contiene la descripción de cada Artículo. ! El Catalogo de Clientes contiene los datos de los clientes.
! La Terminal de Punto de Venta puede realizar Ventas. ! Cada Venta genera una Factura.
! Cada Venta hace uso del Catalogo de Productos. ! La Factura hace uso del Catalogo de Clientes.
*
Datos del Cliente
0..*
1..*
*
Especificación del Producto Venta
1..*
Terminal de Punto de Venta
0..* realiza * Catalogo de Productos * contiene usa * Artículo Almacen proporciona * almacena Vivero 1..* tiene tiene Catalogo de Clientes * contiene * cuenta con Factura 1..* genera usa
Figura # 12, Modelo Conceptual, versión preliminar. Caso de Uso Facturación Versión 1
6.4.5 Agregando Atributos. [Proceso] Un atributo es un dato que representa un valor lógico de un objeto.
El agregar atributos consiste en identificar la información necesaria para satisfacer los requerimientos del caso de uso bajo desarrollo.
Es necesario tener presente que le Modelo Conceptual es una representación de cosas del mundo real, no representan componentes de software, cualquier atributo deberá interpretarse en el contexto de entidad del mundo real.
En el modelo conceptual se deben incluir aquellos atributos para los cuales se requiera recordar cierta información de acuerdo a los requerimientos.
Hay algunas sugerencias que se deben tomar en cuenta cuando se definan atributos. 1. Deberá se simple, un valor. Por ejemplo; datos boléanos, números, cadenas, tiempo. 2. Algunos tipos de atributos incluyen; direcciones, color, números telefónicos, números
del seguro social, códigos postales, tipos enumerados.
3. El tipo de un atributo puede expresarse también como un tipo no primitivo: a) Si el valor esta compuesto de secciones separadas.
Si al número de teléfono se le agrega el nombre de la persona. b) Hay operaciones asociadas con análisis de cadenas o validación.
Un número de seguro social. c) Si se tienen otros atributos.
Un precio promocional, deberá tener también fecha de inicio y fin. d) Cuando se usan cantidades y unidades.
Una cantidad a pagar, tiene además una unidad secuencial.
Habiendo definido los conceptos con sus asociaciones se pasa a agregar los atributos que son necesarios para entender el comportamiento del sistema.
Considerando los conceptos mostrados en el diagrama del Modelo Conceptual. Los atributos encontrados para el vivero son:
[Caso de Estudio] ! Terminal de Punto de Venta.
o Numero de terminal. ! Vivero.
o Nombre o RFC
o Dirección. Es un atributo compuesto. ! Artículo.
! Catalogo de Productos. ! Especificación del producto.
o Número de producto. o Descripción.
o Precio ! Catalogo de Clientes ! Datos del cliente.
o Número de cliente. o Nombre.
o RFC
! Almacén ! Factura. o Número de factura. o Fecha. o Importe. ! Venta. o Cantidad.
Modelo conceptual para el caso de uso Facturación Versión 1, resulta:
6.4.6 El Glosario.
Se crea durante la fase de Planificación y Elaboración conforme se van generando términos, siendo continuamente refinado durante cada ciclo de desarrollo, conforme se van
*
Datos del Cliente numero nombre RFC direccion 0..* 1..* *
Especificación del Producto numero descripcion precio Venta cantidad 1..*
Terminal de Punto de Venta numero 0..* realiza * Catalogo de Productos * contiene usa * Artículo Almacen proporciona * almacena Vivero nombre RFC direccion 1..* tiene tiene Catalogo de Clientes * contiene * cuenta con Factura numero fecha importe 1..* genera usa
Figura # 13, Modelo Conceptual Versión 1, con atributos Caso de uso Facturación Versión 1.
generando nuevos términos. El mantenimiento del glosario, es una actividad continua durante el desarrollo del proyecto.
Glosario de términos (Parte 2).
TERMINO CATEGORIA COMENTARIOS
Terminal de Punto de Venta.
Concepto Lugar destinado al cobro de los artículos seleccionados por el Cliente.
Vivero Concepto Comercio dedicado preponderantemente a la
venta de plantas.
Especificación del Producto Concepto Datos necesarios para la identificación y comercialización de cada artículo.
Datos del Cliente Concepto. Información necesaria de cada cliente para su identificación.
Almacén Concepto Lugar físico donde se tienen resguardados los
artículos.
Venta Concepto Transacción financiera por medio de la cual se
transfiere uno o mas artículos al Cliente. Cantidad Atributo Número de artículos entregados al Cliente.
Número Atributo En cada concepto donde se usa, representa la
identificación alfanumérica del Concepto.
Nombre Atributo En cada concepto donde se usa, representa la
identificación textual del Concepto.
Descripción Atributo Breve reseña de las características mas
importantes del artículo.
RFC Atributo Contracción de Registro Federal de Causantes.
En los conceptos donde se usa, representa la identificación Fiscal del Concepto.
Dirección Atributo Una serie de datos para identificar el lugar físico del Vivero o del Cliente.
Fecha Atributo Valor temporal que indica el día, mes y año en
que se facturó el artículo.
Importe Atributo Valor monetario total de la Factura que debe
pagar el Cliente para poder llevarse los artículos.
6.5 Comportamiento del Sistema. Diagramas de Secuencia del Sistema [Proceso] Los Diagramas de Secuencia del Sistema muestras los eventos que realizan los actores sobre el sistema . Este tipo de diagramas ayudan a descubrir las acciones de los actores sobre el sistema, ya que desde la perspectiva del actor, el sistema se ve como una caja negra. pueden ser parte de la etapa de investigación.
Es conveniente la elaboración de este tipo de diagramas en la fase de análisis de cada ciclo de desarrollo, para descubrir acciones no visualizadas en las etapas anteriores.
6.5.1 Diagramas de secuencia.
Los casos de use sugieren la forma de interactuar de los actores con el sistema, en este proceso un actor genera eventos sobre el sistema, siendo éstos una parte importante en la comprensión del comportamiento de sistema.
Un Diagrama de Secuencia del Sistema, es una representación que nuestra, para un escenario particular de caso de uso, los eventos que actores externos generan, su orden y los eventos intermedios Casos de Uso: Expandido y Esencial Diagrama de Caso de Uso Contratos Diagrama de Secuencia del Sistema Glosario Modelo Conceptual Diagrama de Estado
Figura # 14, Diagrama de Dependencias del Análisis, Diagramas de Secuencia del Sistema..
Un Diagrama de Secuencia del Sistema deberá hacerse para el curso de eventos típico del caso de uso, y tal vez elaborar otros diagramas de secuencia para el curso de eventos de otras alternativas interesantes.
Como hacer un diagrama de secuencia del sistema:
1. Dibujar una línea representando al sistema como una caja negra.
2. Identificar cada actor que opera directamente con el sistema. Dibujar una línea para cada actor.
3. Desde el texto del curso de eventos típico del caso de uso, identificar los eventos externos que cada actor genera. Ilustrarlos en el diagrama.
4. Se puede incluir el texto del caso de uso al lado izquierdo del diagrama.
6.5.2 Curso de eventos típico del caso de uso Facturación Versión 1 [Caso de Estudio] Re-escribiendo el Curso de eventos del caso de uso bajo análisis.
Curso de Eventos típico: Facturación Versión 1.
No Acción del Actor No Respuesta del Sistema
1. Este caso de uso inicia cuando el Cliente llega a la Terminal de Punto de Venta con los productos que desea adquirir. 2. Para cada artículo el vendedor introduce
la clave del producto.
3. Una vez introducida la clave del artículo se muestra su descripción y precio de lista
4. El vendedor teclea el número de artículos vendidos.
5. Se muestra el total del importe por artículo.
6. Una vez terminada la captura de todos los artículos. el vendedor indica que ha terminado.
7. Se despliega el total de la venta.
8. Se introduce el número de cliente. 9. Se despliegan los datos del cliente. 10. Se imprime la Factura. : Vendedor : Sistema 1: entra_articulo(numero, cantidad) 2: fin_venta() 3: entra_cliente(numero) 1 Inicia cuando el Cliente
llega a la Terminal de Punto de Venta con los artículos.
2. Para cada artículo el Vendedor introduce la clave del producto. 3. Una vez terminada la captura de todos los artículos el Vendedor indica que ha terminado. 4. Se introduce el numero de cliente. (para generar la factura)
6.5.3 Comportamiento del Sistema, Contratos. [Proceso] Los Contratos ayudan a definir el comportamiento del sistema, describen el efecto de las operaciones sobre el sistema. La creación de contratos de operación del sistema se lleva a cabo durante la fase de análisis dentro del ciclo de desarrollo correspondiente. La dependencia de la creación de los Contratos se muestra en la Figura # 16.
6.5.4 Comportamiento del Sistema.
Antes de iniciar el diseño lógico de la forma en que el sistema deberá trabajar, es necesario investigar y definir su comportamiento como una caja negra. El Comportamiento del sistema es una descripción de lo que el sistema realiza, sin importar cómo lo hace. Los contratos son un documento útil para describir el comportamiento del sistema en función del cambio de estado que experimenta el sistema cuando se invoca una operación.
6.5.5 Contratos del Caso de uso Facturación Versión 1. Casos de Uso: Expandido y Esencial Diagrama de Caso de Uso Contratos Diagrama de Secuencia del Sistema Glosario Modelo Conceptual Diagrama de Estado
Figura # 16, Diagrama de dependencias de los Contratos.
:Sistema entra_articulo() fin_venta() entra_cliente()
Los contratos se escriben para cada operación del sistema de tal manera de describir el
comportamiento del sistema
6.5.6 Secciones de un contrato
En la tabla #14 se muestra la descripción de cada una de las secciones de un contrato. No todas las secciones son necesarias, sin embargo, se recomienda no omitir las secciones de Responsabilidades y Post-condiciones.
SECCIONES DE UN CONTRATO
Nombre Nombre de la operación y sus parámetros
Responsabilidades Descripción informal de las responsabilidades que deben cumplir las operaciones.
Tipo Nombre del tipo. (concepto, clase, interfase)
Referencias cruzadas Número de referencia de las funciones del sistema, casos de uso, etc.
Notas Notas del diseño, algoritmos, etc.
Excepciones Casos excepcionales.
Salida Salidas de la Interfase de Usuario, tales como mensajes o registros enviados fuera el sistema.
Pre-condiciones Asume el estado del sistema antes de la ejecución de la operación.
Post-condiciones Asume el estado del sistema después de que la operación ha concluido.
Tabla # 14, Secciones de un Contrato.
6.5.6 Como hacer un contrato.
1. Identificar las operaciones del sistema desde el diagrama de secuencia. 2. Para cada operación del sistema construir un contrato.
3. Iniciar escribiendo la sección de responsabilidades, describiendo informalmente el propósito de la operación.
4. Ahora se completa la sección de Post-condiciones, declarativamente describiendo los cambios de estado que le ocurren a los objetos en el modelo conceptual.
5. Para describir las Pos-condiciones, se recomienda usar las siguientes categorías. • Creación y eliminación de instancias.
• Modificación de atributos
6.5.6 Contratos para el caso de uso Facturación Versión 1. [Caso de Estudio]
CONTRATO: entra_articulo()
Nombre entra_Artículo(numero, cantidad)
Responsabilidad Registrar la compra de un articulo, añadirlo a la venta total, desplegar precio de lista y su descripción.
Cuando se introduce la cantidad de artículos despliega el precio total por artículo.
Tipo Sistema.
Referencia cruzada R4, R5, R6
Notas Accesa el Catalogo de Productos.
Excepciones Envía un error si no existe el artículo.
Salida Muestra la descripción del artículo, su precio de lista y el importe total por artículo.
Pre-condición Es necesario conocer la clave del producto y la cantidad de productos solicitada por el Cliente. Post-condición • Al introducir el primer artículo, se crea una
nueva instancia de Factura y una colección vacía de Venta.
• Se crea una asociación con el producto. • Al introducir la cantidad de productos, se
modifica el atributo Venta.cantidad.
CONTRATO: fin_venta()
Nombre fin_venta( )
Responsabilidades Termina el proceso de captura de artículos, calcula el importe total de la venta.
Tipo Sistema
Referencias cruzadas R7 Notas
Excepciones
Salida Se muestra el importe total de la Venta. Pre-condiciones
Post-condiciones ! Se actualiza su numero (el cual es consecutivo.
! Se actualiza la fecha con la del sistema. ! Se almacena el importe total de la factura.
CONTRATO: entra_cliente
Nombre entra_cliente(numero)
Responsabilidades Accesar los datos del cliente para incluirlos en la Factura.
Tipo Sistema
Referencias cruzadas R3
Notas Accesa el Catalogo de Clientes.
Excepciones Envía un error si no existe el Cliente.
Salida Muestra los datos del Cliente. Se imprime la factura. Pre-condiciones Es necesario conocer la clave del cliente.
Post-condiciones
6.5.7 Pre-condiciones.
Las Pre-condiciones definen suposiciones acerca del estado del sistema al iniciarse la operación. Existen muchas Pre-condiciones que se pueden declarar para una operación, sin embargo, la experiencia sugiere que las siguientes son las mas notorias.
• Cosas importantes de probar en el software durante algún punto durante la ejecución de la operación.
• Cosas que no van a ser probadas, pero que son importantes para la ejecución de la operación y que hay que tener en cuenta en el futuro.
6.5.8 Post-condiciones.
Las Post-condiciones se expresan en el contexto del Modelo Conceptual. Es común que durante la creación de contratos descubrir la necesidad de agregar nuevos conceptos, atributos o asociaciones al modelo conceptual.
Una ventaja al usar las Post-condiciones expresadas como declaraciones de cambio de estado, se ve que el contrato es una excelente herramienta de investigación para describir los cambios de estado requeridos por una operación del sistema sin tener que describir como son realizados dichos cambios. Dicho en otras palabras el Diseño del software puede diferirse y enfocarse analíticamente sobre lo que deberá hacer, en vez de cómo deberá ser realizado.
En la etapa del análisis, el desarrollo se enfatiza en el entendimiento de los requerimientos, conceptos y operaciones relacionadas con el sistema.
