Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

UNIDAD III

PARADIGMAS DE LA INGENIERA DE SOFTWARE

Paradigma: Ejemplo o modelo La ingeniera de software abarca un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo de software y suministran las bases para construir software de calidad de una forma productiva: 1. Mtodos: Indican cmo construir el software tcnicamente e incluyen un amplio espectro de mtodos para la planificacin, la estimacin, el anlisis, el diseo, codificacin, prueba y mantenimiento. 2. Herramientas: (automticas y semiautomticas) que apoyan a la aplicacin de los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una herramienta puede ser usada por otra, se establece un sistema para el soporte del desarrollo de software, llamado Ingeniera de Software Asistida por Computadora (CASE). 3. Procedimientos: Definen la secuencia en la que se aplican los mtodos, las entregas, los controles de calidad y guas para evaluacin del progreso. La Ingeniera de Software est compuesta por una serie de pasos que abarcan los mtodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniera de Software. 1.1 El enfoque estructurado

En ste enfoque se usan los Diagramas de Flujos de Datos (FDF) como principal herramienta para entender al sistema antes de plasmarlo a cdigo fuente. Respecto a los lenguajes de programacin existen varias desventajas una de ellas es cuando una porcin de cdigo en lenguaje estructurado es difcil que pueda servir en otros proyectos, en la programacin Orientada a Objetos, con solo importar clases ya hechas se escribe menos cdigo y se ahorra tiempo. 1.1.1 Diagramas de flujos de datos Un diagrama de flujo de datos (DFD) es un modelo lgico-grfico para representar el funcionamiento de un sistema en un proyecto software. Es un diagrama en el que participan procesos (mtodos), flujo de datos (argumentos) y archivos (base de datos). Sus elementos grficos son crculos, flechas, y rectngulos cerrados o abiertos. Los cerrados representan entidades
1

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

externas como los usuarios y las impresoras mientras que los abiertos describen almacenes o archivos (lugares donde residen los datos), indicando el nombre del almacn de datos. Los crculos significan procesos (algunos autores los procesos tambin los representan con rectngulos) y las flechas flujos de datos desde, o hacia, un proceso. En un DFD tambin se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cmo el sistema se pondr en prctica. La manera en que cualquier sistema es desarrollado puede determinarse a travs de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificacin de los datos de la transaccin en el modelo de datos. Ejemplo: La compaa CBM es una distribuidora de libros, actualmente sus clientes son totalmente libreras. La distribucin de libros se basa en el siguiente proceso: Recibir las requisiciones u rdenes de las libreras por correo. Solicitar los libros a los editoriales, satisfacer las requisiciones de las libreras. En cuanto se reciben los libros de los editoriales, satisfacer las requisiciones de las libreras. Las facturas las procesa un Servicie Bureau a partir de formas llenas por la CBM. Se procesan aproximadamente 100 facturas por da, con un promedio de 4 libros y un valor promedio de $10,000.00 MN por factura. Se planea expandir la operacin considerablemente mejorando los niveles de servicio manteniendo stocks de los 100 libros ms frecuentemente ordenados y hacer posible el servicio al pblico (adems de las libreras) solicitando los
2

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

libros por telfono o por correo como se hace actualmente. Esto provocar problemas en la verificacin de crditos y crear la necesidad de tener un sistema de control de inventarios. La gente que tome las rdenes por telfono necesitar tener un acceso rpido al catlogo de libros para verificar autores y ttulos, a efecto de poder responder a los solicitantes qu libros se tienen disponibles en algn tpico dado. Se estima que con este mtodo, el volumen de transacciones crezca a 1000 facturas por da o ms, aunque con un promedio ms bajo de libros que el pblico. A usted, como analista, se le ha pedido que haga la investigacin y especifique el nuevo sistema, produciendo un modelo lgico del sistema requerido, de donde puedan sacarse conclusiones sobre: Qu partes del sistema deben automatizarse? Cules deben ser procesadas en forma manual? Se debe seguir usando el Servicie Bureau se tiene que comprar una computadora e instalar todo el sistema? Si se automatiza, que parte debe ser procesada en lnea y cual en proceso Batch

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

1.1.2 Diccionario de Datos Es un conjunto de metadatos que contiene las caractersticas lgicas y fsicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. El objetivo de un diccionario de datos es definir con precisin los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc. El diccionario de datos guarda los detalles y descripcin de todos estos elementos.
4

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

Se desarrollan durante el anlisis de flujo de datos y ayuda a los analistas que participan en la determinacin de los requerimientos del sistema, su contenido tambin se emplea durante el diseo del proyecto.

Atributo 1. Identificacin Nombre Abreviatura Contenido Significado Nombre del empleado NOM - EMP Nombre y apellidos del empleado Nombre de identificacin de la persona Nombre dado al empleado 5

Atributo

Sueldo Suel Emp Monto salarial La cantidad que percibe el empleado Convenio

Fuente - Origen

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

2. Manejo Alta Actualizacin Cuando ingresa el empleado Slo en casos de correccin Cuando ingresa En aumentos al tabulador y por promocin Cuando renuncia

Baja

Cuando renuncia el empleado

3. Nivel de acceso Confidencialidad Personal autorizado baja Consultas: todos Cambio: Depto. Recursos Humanos Alta Slo Depto. de Recursos Humanos

4. Relaciones Archivo Documentos Kardex de empleados, etc. Solicitud de empleo, acta de nacimiento, etc. Plantilla, nmina, etc. R.F.C Kardex Contrato, cheque, etc.

Reportes Otros datos

Nmina Tabulador de sueldos

5. Fsicas

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

Tipo Longitud Rango de valores Criterio de validacin

Alfabtico 40 caracteres Infinito

Numrico Ocho enteros y dos decimales Hasta 7,000,000.00

Alfabtico y diferente de blanco Numrico menor o igual a 7,000,000.00 y mayor = a 0 $$,$$$,$$, 9.99

Formato de edicin Normal

1.1.3 Diseo de mdulos Un Diagrama de Flujo de Datos puede ser subdividido en diferentes partes, a las cuales se les llama mdulos conteniendo cada uno de ellos procedimientos, programas, relacin de operaciones etc. Por ejemplo, el mdulo de ventas, compras y en cada uno de ellos especificar con detalle las actividades que se realizarn. Tambin incluye el diseo de la interfaz que tendrn los mdulos.

1.1.4 Descomposicin en procesos El proceso es un conjunto de tareas lgicamente relacionadas que existen para obtener un resultado bien definido dentro de un negocio.

Con enfoque a POO

Una descripcin de un caso de uso especfico se debe orientar hacia qu es lo que ese usuario hara all en interaccin con un sistema. Por lo tanto si se tiene un caso de uso llamado Registrar inventario, en la descripcin no puede haber un paso que diga el usuario registra el inventario y listo, puesto que eso es precisamente lo que se pregunta, como se registra, (los pasos), los datos que se manipulan y que operaciones se hacen con ellos. Para que posteriormente un desarrollador pueda crear las pantallas y mens

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

1.2

El enfoque orientado a objetos

Thomas K. describa un paradigma como un conjunto de teoras, estndar y mtodos que juntos representan un medio de organizacin del conocimiento: es decir, un medio de visualizar el mundo. En este sentido, la programacin orientada a objetos es un nuevo paradigma. Las tcnicas orientadas a objetos proporcionan mejoras y metodologas para construir sistemas de software complejos a partir de unidades de software modularizado y reutilizable. La Programacin Orientada a Objetos desde el punto de vista computacional "es un mtodo de implementacin en el cul los programas son organizados como grupos cooperativos de objetos, cada uno de los cuales representa una instancia de alguna clase, y estas clases, todas son miembros de una jerarqua de clases unidas va relaciones de herencia" Un objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). La estructura y comportamiento de objetos similares estn definidos en su clase comn; los trminos instancia y objeto son intercambiables.

Un atributo puede tomar un valor definido por un dominio enumerado. Un dominio es simplemente un conjunto de valores especficos. En situaciones ms complejas el dominio puede ser un conjunto de clases.

Una clase es un conjunto de objetos que comparten una estructura y comportamiento comn. Todos los objetos que existen dentro de una clase heredan sus atributos y las operaciones disponibles para la manipulacin de los atributos. Una superclase es una coleccin de clases. Los principios del modelo OO son: abstraccin, encapsulacin, modularidad y jerarqua fundamentalmente y en menor grado tipificacin (typing),
8

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

concurrencia, persistencia. Si un modelo que se dice OO no contiene alguno de los primeros cuatro elementos, entonces no es OO. Abstraccin. Es una descripcin simplificada o especificacin de un sistema que enfatiza algunos de los detalles o propiedades del sistema, mientras suprime otros.
1.

Encapsulacin. En el proceso de ocultar todos los detalles de un objeto que no contribuyen a sus caractersticas esenciales.
2.

Modularidad. Es la propiedad de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes.
3. 4. 5.

Jerarqua. Es el orden de las abstracciones organizado por niveles.

Tipificacin. Es la definicin precisa de un objeto de tal forma que objetos de diferentes tipos no puedan ser intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida. Concurrencia. Es la propiedad que distingue un objeto que est activo de uno que no lo est.
6.

Persistencia. Es la propiedad de un objeto a travs de la cual su existencia trasciende el tiempo (es decir, el objeto continua existiendo despus de que su creador ha dejado de existir) y/o el espacio (es decir, la localizacin del objeto se mueve del espacio de direccin en que fue creado).
7.

La herencia funciona de la siguiente forma: una subclase hereda todos los atributos y operaciones asociadas con su superclase. 9. El polimorfismo permite que un nmero de operaciones diferentes tengan el mismo nombre. Esto reduce el acoplamiento entre objetos, haciendo a cada uno ms independiente.
8.

1.2.1 Anlisis El Anlisis Orientado a Objetos (OOA por sus siglas en ingls de Object Oriented Analysis) examina los requerimientos desde la perspectiva de las clases y objetos; identificando los objetos, su comportamiento, relaciones, clasificacin y organizacin.
9

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

El modelo de anlisis est compuesto por tres modelos individuales: 1. El modelo funcional, representado por casos de uso y escenarios. 2. El modelo de objetos de anlisis, representado por diagramas de clase y objeto 3. El modelo dinmico, representado por grficas de estado y diagramas de secuencia. En lugar de considerar el SW desde una perspectiva bsica de entrada-procesosalida como los mtodos estructurados se basa en modelar el sistema mediante los objetos que forman parte de l y las relaciones estticas (herencia y composicin )o dinmicas (uso entre otros objetos ). 3.2.2 Diseo El Diseo Orientado a Objetos es un mtodo de diseo abarcando el proceso de descomposicin orientado a objetos y una notacin para representar ambos modelos lgico y fsico. El diseo proporciona detalles sobre la arquitectura, las interfaces y los componentes. El modelo de casos de uso, permite hacer una mejor toma de requerimientos y clarificacin de la funcionalidad del sistema. Los casos de uso son descripciones narrativas del comportamiento de los objetos dentro del sistema, gracias a las cuales podemos mejorar la comprensin de los requerimientos funcionales del mismo. Estas descripciones cubren tanto el comportamiento normal del sistema, como todas las variantes, de xito o de fracaso, que pudieran originarse durante un proceso. Un caso de uso: describe la secuencia de eventos y acciones que se producen entre un Actor y un Sistema que interactan para cumplir un objetivo. (Se ponen de manera general los procesos no con lujo de detalle) Identificar los Casos de Uso del sistema Existen dos mtodos para identificar los casos de uso:

Identificacin basada en los actores: (usuario, administrador, alumno, profesor, etc)

1. a. Se identifican los actores.
10

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

Averiguamos qu procesos inician o en cules participan: i. Cules son sus responsabilidades, de qu tareas se encargan: Crear/Modificar/Eliminar elementos, Introducir/Obtener datos, Mantenimiento/Soporte del sistema?. ii. Debern informar al sistema sobre algn evento externo que se produzca (ej. Llegada de ficheros de datos a su destino, listos para ser procesados)? iii. Deben ser informados por el sistema sobre algn evento que se produzca (ej.: Error en la ejecucin de un proceso desatendido)?. iv. Necesitan indicar al sistema que efecte algn proceso concreto en un momento determinado (ej.: Realizar una copia de seguridad de los datos del perodo)?. Se identifican los eventos ante los que el Sistema debe reaccionar. i. Creacin/Modificacin/Eliminacin de elementos. ii. Entrada/Solicitud de datos por parte de algn actor. iii. Orden de ejecucin de algn proceso. iv. Notificaciones sobre eventos externos al sistema (p.ej.: El paso del tiempo). v. Es necesario que algn actor sea informado sobre ciertos cambios o acontecimientos que se produzcan en el sistema? vi. Cualquier otro evento ante el cual el sistema deba reaccionar. b. Se relacionan los eventos con actores y con casos de uso.

b.

2.
a.

Identificacin basada en los eventos:

Al finalizar, se debe hacer una ltima pregunta: Los casos de uso que se han identificado son capaces de cubrir todos los requisitos funcionales que se tienen anotados? Errores comunes en la identificacin de Casos de Uso Hay que recordar que un caso de uso est formado por un conjunto de pasos o transacciones necesarios para cumplir un proceso. Sin embargo, un error comn en la identificacin de casos de uso, es representar los pasos, las operaciones o las transacciones individuales, como casos de uso. Por ejemplo: Imprimir Factura sera un caso de uso errneo, puesto que en realidad se trata de un paso u operacin del caso de uso Comprar Producto/Servicio. No obstante hay
11

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

ocasiones en las que un paso o transaccin de un caso de uso merece ser representado como un caso de uso aparte.

Los actores no forman parte del sistema. Un actor es una entidad externa al sistema que de alguna manera participa en el caso de uso. Generalmente estimula al sistema con eventos de entrada, o bien recibe algo de l. Los Actores juegan Roles Un actor puede representar bien el cargo de la persona que usa el sistema, o bien el rol que esa persona est jugando en el momento de usar el sistema. Realmente no es significativo cul de estos modos se empleen para referirse al trmino actor. Lo verdaderamente importante es el objetivo que cada caso de uso pretende cumplir, ya que dice lo que el sistema va a hacer. Los diagramas de casos de uso tienen por objeto permitir conocer rpidamente los actores externos del sistema, y las formas bsicas en que lo utilizan. Un diagrama de casos de uso: 1. Explica grficamente un conjunto de casos de uso, normalmente agrupados por funcionalidad. 2. Representa la relacin entre los actores y los casos de uso. 3. Describe la interaccin de los actores con el sistema. Un caso de uso puede contener puntos de decisin. Por ejemplo, en una compra, el cliente puede optar por distintas formas de pago (efectivo, tarjeta, cheque, ...) Si una de las trayectorias de decisin es muy representativa, y las otras son alternativas poco frecuentes, el caso tpico ser sobre el que se describa el curso normal, y las otras opciones se describirn como cursos alternativos. Pero para los casos en los que todas las opciones son igualmente importantes y de uso frecuente, podemos seguir la siguiente notacin: 1. En la seccin principal curso normal se indicarn las ramificaciones. 2. Se crear una subseccin por cada ramificacin, siguiendo el esquema de descripcin acostumbrado.
12

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

3. Si alguna subseccin tiene a su vez ramificaciones, se describirn como cursos alternativos de esa subseccin.

Ejemplo:

Procesos que se llevan antes de otro proceso

Caso de Uso Actor Extends Include Pre-condiciones Pos-Condiciones

Registrar Solicitud Ciudadano y Responsable del Modulo de Atencin Ciudadana Registrar departamento y Registrar ciudadano Ninguno Sistema Operando Solicitud Registrada

13

Fundamentos de Desarrollo de Sistemas

Unidad III Paradigmas de la Ingeniera de Software

1. Flujo de Eventos

Flujos Alternativos

El ciudadano llega al modulo de atencin e indica que desea realizar una solicitud. 2. El responsable del MAC indica al sistema que desea registrar una solicitud. 3. El responsable del MAC busca en el sistema al ciudadano, si el ciudadano ya est registrado avanza al paso 5. 4. De lo contrario ir a flujo alternativo nuevo ciudadano. 5. El responsable del MAC solicita y captura los datos de la solicitud. 6. El responsable del MAC elige en el sistema el departamento que deber atender la solicitud, en caso de que el departamento no est registrado ir al caso de uso Nuevo Departamento. 7. El sistema calcula la fecha lmite para la atencin de la solicitud y el responsable del MAC le informa de la fecha al ciudadano. 8. El responsable del MAC indica al sistema guardar la solicitud. 9. El sistema registra los datos en la Base de Datos 10. Termina Flujo 1. Nuevo ciudadano: Ir a caso de uso Registrar Ciudadano 2. Nuevo Departamento: Ir al caso de uso nuevo departamento

Caso de Uso Actor Extends Include Pre-condiciones Pos-Condiciones Flujo de Eventos

Registrar Ciudadano Responsable del Modulo de Atencin Ciudadana Ninguno Ninguno Sistema Operando Ciudadano Registrado 1. Inicia el flujo 2. El responsable del MAC indica al sistema que desea registrar a un ciudadano y el sistema solicita los datos. 3. El responsable del MAC solicita los datos del ciudadano y su credencial de elector para corroborar datos. 4. El responsable del MAC captura los datos e indica al sistema que los guarde. 5. El sistema registra los datos en la Base de Datos 6. Termina el flujo Ninguno

Flujos Alternativos

14