1

2.1 METODOLOGA RUP. El Proceso Unificado de Racional (Rational Unified Process en ingls, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos. RUP es un producto del proceso de ingeniera de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organizacin del desarrollo. Su meta es asegurar la produccin del software de alta calidad que resuelve las necesidades de los usuarios dentro de un presupuesto y tiempo establecidos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. Tambin se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye informacin entrelazada de diversos artefactos y descripciones de las diversas actividades. Est incluido en el Rational Method Composer (RMC), que permite la personalizacin de acuerdo a necesidades. Dimensiones del RUP El RUP tiene dos dimensiones: 1. 2. El eje horizontal representa tiempo y demuestra los aspectos del ciclo de vida del proceso. El eje vertical representa las disciplinas, que agrupan actividades definidas lgicamente por la naturaleza.

La primera dimensin representa el aspecto dinmico del proceso y se expresa en trminos de fases, de iteraciones, y la finalizacin de las fases. La segunda dimensin representa el aspecto esttico del proceso: cmo se describe en trminos de componentes de proceso, las disciplinas, las actividades, los flujos de trabajo, los artefactos, y los roles. PRINCIPALES CARACTERSTICAS 1. Forma disciplinada de asignar tareas y 4. 5. 6. 7. 8. Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software

responsabilidades (quin hace qu, cundo y cmo) 2. Pretende implementar las mejores prcticas en Ingeniera de Software 3. Desarrollo iterativo

ELEMENTOS EN RUP Entre los elementos que lo componen se tienen: Flujos de Trabajo, Detalle de los Flujos de Trabajo , Actores, Actividades y Artefactos. En la figura se muestra ms claramente como se representan grficamente cada uno de estos elementos y la interrelacin entre ellos. Se puede observar que el Flujo de Trabajo de Requerimientos conlleva varios pasos, cada uno de estos pasos tiene asociado uno o varios actores, los cuales a su vez son los encargados de la ejecucin de varias actividades, las cuales a la vez estn definidas en artefactos o guas para su realizacin.

Fases del Modelo RUP RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades. Inicio Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Elaboracin En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Construccin El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Transicin El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto. 2.2 DIAGRAMAS UML ESTTICOS El Lenguaje Unificado de Modelado, UML es una notacin estndar para el modelado de sistemas software, resultado de una propuesta de estandarizacin promovida por el consorcio OMG ( Object Management Group), del cual forman parte las empresas ms importantes que se dedican al desarrollo de software, en 1996. UML representa la unificacin de las notaciones de los mtodos Booch, Objectory (Ivar Jacobson) y OMT (James Rumbaugh) siendo su sucesor directo y compatible. Igualmente, UML incorpora ideas de otros metodlogos entre los que se pueden incluir

3
a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin, Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs- Brock y Ed Yourdon. UML no es un proceso de desarrollo, es decir, no describe los pasos sistemticos a seguir para desarrollar software. UML slo permite documentar y especificar los elementos creados mediante un lenguaje comn describiendo modelos. UML es un lenguaje de propsito general para el modelado orientado a objetos, que combina notaciones provenientes desde: Modelado Orientado a Objetos, Modelado de Datos, Modelado de Componentes, Modelado de Flujos de Trabajo (Workflows). 2.2.1 DIAGRAMAS DE CLASES En el diagrama de clases ser donde definiremos las caractersticas de cada una de las clases y relaciones de dependencia y generalizacin. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseo orientado a objetos, definiendo las clases e implementando las ya tpicas relaciones de herencia y agregacin. Este diagrama sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenido. Se utiliza cuando necesitamos realizar un Anlisis de Dominio: El analista se entrevista con el cliente con el objetivo de conocer las entidades principales en el dominio del cliente. Durante la conversacin entre el cliente y el analista se deben tomar apuntes. Desde estos apuntes, se buscarn las clases para los objetos del modelo buscando los sustantivos (ej.: proveedor, pedido, factura, etc.) y convirtindolos en clases. Despus se ver que algunos de estos sustantivos

pueden ser atributos de otros en vez de entidades por si mismas. Tambin se buscarn los mtodos para estas clases buscando los verbos (ej: Calcular, imprimir, Agregar,..). Nos muestra una vista de la aplicacin en un determinado momento, en un instante en que el sistema est detenido. ELEMENTOS Un diagrama de clases est compuesto por los siguientes elementos: Clase: atributos, mtodos y visibilidad. Relaciones: Herencia, Asociacin, Ensamblado y Uso.

Pasos para crear el diagrama de clases: 1. 2. 3. Identificar las clases, nombrarlas y definirlas. Mostrar los atributos y operaciones Identificar, nombrar y definir las asociaciones entre pares de clases. Tener cuidado con clases reflexivas. 4. Etiquetar asociaciones y en caso necesario los roles 8. 5. 6. 7. Indicar multiplicidad Dibujar flechas de direccin Evaluar cada asociacin para determinar si debe ser una agregacin y cada agregacin para ver si debe ser composicin. Evaluar las clases para encontrar posible

generalizacin (herencia).

Ejemplo 1: Una Cuenta Corriente que posee como caracterstica, nombre de la clase: Cuenta. Balance (Atributo de la clase cuenta y es del tipo entero) Puede realizar las operaciones o mtodos de: Depositar (es la accin de depositar dinero a la cuenta y para ello necesita el monto de dinero a depositar y este es del tipo entero). Girar (es un mtodo que sirve para realizar un giro de la cuenta, necesita como datos el monto de dinero a girar y es del tipo entero y este obtiene como valor un dato booleano o sea si se realiz o no el giro). procedimiento el cual devuelve el balance actual de la cuenta) y Balance (que es un

4
El diseo asociado a esta clase es: Ejemplo 2: Es un ejemplo de diagrama de clase con cada uno de los atributos y las asociaciones correspondientes a cada clase. La clase Persona tiene un Nombre, Direccin, y Nmero del Seguro Social. Una persona puede trabajar en algn proyecto y ganar un salario. Una Compaa tiene un Nombre, Direccin, Nmero de Telfono, y Producto Primario. Una Compaa contrata y despide Personas. Persona y Compaa tienen una relacin "muchos-muchos". El ttulo del trabajo depende de la persona y de la compaa. Hay dos tipos de Personas: Trabajadores y Administradores. Cada Trabajador est involucrado en varios Proyectos; cada Administrador es responsable de varios proyectos. En un proyecto pueden trabajar varios trabajadores y un solo administrador. Cada proyecto tiene un Nombre, Presupuesto, y una Prioridad Interna para asegurar recursos. Adems una Compaa est compuesta de mltiples Departamentos; cada departamento dentro de una compaa se identifica de forma nica por su Nombre. Un departamento usualmente tiene un administrador. La mayora de los administradores manejan un departamento; y algunos administradores no estn asignados a ningn departamento. Cada departamento manufactura varios productos; mientras que cada producto est hecho por un solo departamento. Un producto tiene Nombre, Costo, y Peso. El diagrama es el siguiente:

5
Superclase y Subclases

El concepto de herencia conduce a una estructura jerrquica de clases o estructura de rbol, lo cual significa que en la OOP todas las relaciones entre clases deben ajustarse a dicha estructura. En esta estructura jerrquica, cada clase tiene slo una clase padre. La clase padre de cualquier clase es conocida como su superclase. La clase hija de una superclase es llamada una subclase. * Una superclase puede tener cualquier nmero de subclases. * Una subclase puede tener slo una superclase.

1. 2. 3. 4.

A es la superclase de B, C y D. D es la superclase de E. B, C y D son subclases de A. E es una subclase de D.

EJERCICIOS Para el registro de vuelos en una aerolnea se tienen las siguientes clases: pasajero, registrador, aeromoza, piloto, vuelo. Cada uno de ellos contiene diferentes atributos y mtodos; describir cada uno de ellos partiendo de lo siguiente: Cuando un pasajero llega a la ventanilla de registro y abordaje de avin es atendido por el registrador de vuelos, el cual chequea el vuelo y pesa y revisa las maletas de viaje, luego el pasajero aborda el avin y es atendido por la jefe de cabina que es la persona encargado/a de instalar al pasajero en el lugar adecuado, luego la aeromoza y el piloto del vuelo dan las indicaciones a los pasajeros para comenzar el vuelo. 2. Se tiene la tienda de libros El Roble donde se comercializan todo tipo de libros y revistas. Se n ecesita modelar el sistema de facturacin de dicha tienda, la cual trabaja de la siguiente forma: El cliente llega y escoge el libro o revista a comprar, para cancelar pasa a la caja registradora donde el empleado de la tienda pasa el articulo por el cdigo de barras y este es ledo y capturado hacia la PC (pone el cdigo y el nombre del producto ), se procede a facturar dicha venta, creando la factura con cada uno de los detalles de la misma (cod_producto, nombre, cantidad, total_sindescuento, descuento (ya que los clientes que posean la tarjeta de cliente frecuente obtienen un descuento de 10%), y total). Dicha factura es impresa y entregada a los clientes junto con el producto. Desarrolle el diagrama de clases para dicha tienda.

6
2.2.2 DIAGRAMAS DE OBJETOS En UML los diagramas de clases se utilizan para visualizar los aspectos estticos de los bloques de construccin del sistema. Los diagramas de interaccin se utilizan para ver los aspectos dinmicos del sistema y constan de instancias de estos bloques y mensajes enviados entre ellos. Un diagrama de objetos contiene un conjunto de instancias de los elementos encontrados en un diagrama de clases. Por lo tanto, un diagrama de objetos expresa la parte esttica de una interaccin, consistiendo en los objetos que colaboran pero sin ninguno de los mensajes enviados entre ellos, es decir que son como fotos instantneas de los diagramas de clases y cubren la vista de diseo esttica o la vista de procesos esttica desde la perspectiva de casos reales o prototpicos. Un diagrama de objetos es simplemente un diagrama que representa un conjunto de objetos y sus relaciones en un momento concreto. Un diagrama de objetos contiene objetos y enlaces. Al igual que los dems diagramas, puede contener notas y restricciones. Los diagramas de objetos tambin pueden contener paquetes o subsistemas, los cuales se usan para agrupar los elementos de un modelo en partes ms grandes. A veces se colocarn clases en los diagramas de objetos, especialmente cuando se quiera mostrar qu clase hay detrs de cada instancia. Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, segn la siguiente sintaxis:
Ejemplo 4: Diagrama de Objetos de la Universidad, la cual contiene las siguientes clases: departamentos, estudiantes, funcionarios, titulacin, Universidad, contratado y asignaturas; cada una de las clases contiene diferentes objetos y los enlaces entre cada uno de ellos.

Ejemplo Diagrama de Objetos de la Universidad, la cual contiene las siguientes clases: departamentos, estudiantes, funcionarios, titulacin, Universidad, contratado y asignaturas; cada una de las clases contiene diferentes objetos y los enlaces entre cada uno de ellos.

7
1. Desarrollar el diagrama de objetos que contiene la clase computadora. (Hacer la clase computadora primero y partir de ella para realizar el diagrama de objetos) 2. Crear el diagrama de objetos de la clase polgono. Partiendo del hecho que un polgono puede ser: un rectngulo, un cuadrado, un triangulo, un pentgono). 3. Elaborar el diagrama de objeto de un sistema de ventas de computadoras (de escritorio y porttiles) y accesorios. (Se venden Mouse, bocinas, cmaras web, audfonos, Ups, micrfonos). Elaborar el diagrama de objetos para un sistema de inscripcin de asignaturas.(con las siguientes clases: estudiante, asignatura, grupo, carrera, docente, trabajador administrativo). Se tiene la biblioteca en la cual se pueden realizar diferentes transacciones: prstamos de libros para consultas internas, prstamos de libros para consultas externas, consulta de revistas y tesis Crear el diagrama de objetos para el sistema de prstamos de libros y revistas de dicha biblioteca. 3. Elaborar el diagrama de objetos para el sistema de alquiler de vehculos, el cual labora de la siguiente manera: Llega el cliente a realizar un alquiler de vehculos, lo atiende un empleado y este toma los datos del vehculo que el cliente quiere, ensea los vehculos al cliente y despus de escogido el vehculo a rentar, el empleado realiza el contrato de renta y la reserva de dicho vehculo. 2.2.3 DIAGRAMAS DE COMPONENTES Muestra el sistema y las dependencias entre un conjunto de componentes. Cubren la vista de la implementacin esttica y se relacionan con los diagramas de clases ya que en un componente suele tener una o ms clases, interfaces y relaciones. Un componente es la parte fsica y reemplazable de un sistema que conforma un conjunto de interfaces y proporciona una implementacin (clases). Su smbolo principal es el siguiente: Cuando se trabaja con componentes, se tendr que trabajar con sus interfaces. El objeto debe presentar un rostro al mundo exterior, para que los dems objetos (incluso los humanos) puedan pedirle que ejecute sus operaciones. A este rostro se le conoce como interfaz del objeto. Una interfaz es un conjunto de operaciones que especfica algo respecto al comportamiento de una clase, por lo cual solo se podr ejecutar las operaciones de un componente a travs de su interfaz. Un componente debe tener un nombre: simple, ej. cliente.java o de camino, cuando est incluido en un paquete. Ej. system::dialog.dll Un componente puede contener adornos, valores etiquetados e informacin adicional. Ej. referencia a las interfaces que realiza.

INTERFACES Tanto los servicios propios de una clase como los de un componente, se especifican a travs de una Interfaz. Por ejemplo, todas las facilidades ms conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unin entre unos componentes y otros. La relacin entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icnica y de forma expandida

Componentes e interfaces formato icnico.

Componentes e interfaces formato extendido.

A continuacin se muestra las relaciones entre un componente y las clases que implementa.

Existen dos formas para representar a un componente y sus interfaces: 1 Forma: Muestra la interfaz como un rectngulo que contiene la informacin que se le relaciona, se conecta al componente por una flecha discontinua representada por un triangulo sin rellenar

2 Forma: esta forma es representativa, ya que representara la interfaz como un pequeo crculo que se conecta al componente por una lnea contina.

10

EJEMPLO: Se muestra el diagrama de componentes de un sistema de ventas desde el componente Compras.exe que ejecuta una comunicacin mediante una interfaz con la librera comunicacin.dll y esta establece un enlace hacia el componente de autenticacin que puede ser un modulo aparte del sistema o incluido en el, despus de establecerse la autenticacin se procede a ejecutarse las transacciones requeridas con los datos necesitados que han sido extrados de una base de datos mediante un componente JDBC.

2.3.1 DIAGRAMA DE CASOS DE USO. Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interaccin externa. La vista de los casos de uso modela la funcionalidad del sistema segn lo perciben los usuarios externos llamados actores.

Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: Actores, casos de uso y relaciones entre casos de uso.

11
Actores Un actor es una entidad externa al sistema que realiza algn tipo de interaccin con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representacin sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.). Un actor es un rol que tiene un usuario con respecto al sistema. Es decir, sera un usuario del sistema. Es importante destacar el uso de la palabra rol, ya que esto especifica que un actor no necesariamente representa a una persona en particular, si no la labor que realiza frente al sistema. Por ejemplo, en un sistema de ventas, el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. Debe tener un nombre significativo y se representa mediante el siguiente grfico Caso de Uso Un caso de uso es una descripcin de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea especfica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea llevar a cabo usando el sistema. Es una operacin o tarea especfica que se realiza tras una orden o estmulo de un agente externo, puede ser un actor o desde la invocacin desde otro caso de uso. Se representa mediante el siguiente grfico: Relaciones entre Casos de Uso Entre dos casos de uso puede haber las siguientes relaciones: Extiende (Extends): Cuando un caso de uso especializa a otro extendiendo su funcionalidad. Un punto de extensin es una entidad con nombre perteneciente a un caso de uso que describe localizaciones en las cuales se pueden insertar secuencias de otros casos de uso. Usa (Uses): Cuando un caso de uso utiliza a otro. (Incluye). Utilice una relacin de incluir para demostrar que un caso de uso describe algunos de los detalles de otro.

El objetivo y los escenarios de un caso de uso include debe tener sentido de forma independiente para que pueda ser incluido en el caso de uso diseado. Se representan como una lnea que une a los dos casos de uso relacionados, con una flecha en forma de tringulo y con una etiqueta <<extender>>, <<usar>> o <<incluir>> segn sea el tipo de relacin. En el diagrama de casos de uso se representa tambin el sistema como una caja rectangular con el nombre en su interior. Los casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido a los casos de uso en los que participa mediante una lnea.

12
EJEMPLOS:

El caso de uso login de un sitio Web puede incluir registrar nuevo usuario, pero solo cuando el usuario no posee una cuenta.

RELACIONES: 1- Asociacin: Es el tipo de relacin ms bsica, indica la invocacin desde un actor o caso de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha simple: 2- Generalizacin: Este tipo de relacin es una de las ms utilizadas, cumple una doble funcin dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relacin est orientado exclusivamente para casos de uso. Extends: se recomienda utilizar cuando un caso de uso es similar a otro (en caractersticas). Uses: se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica. Se representa con la siguiente flecha:

13
Relaciones de Inclusin Dos casos de uso estn relacionados por una relacin de inclusin, si alguno de ellos incluye al segundo en su flujo de eventos. En UML las relaciones de inclusin se muestran mediante una flecha de guiones que se inicia en el caso de uso que incluye al otro. Las relaciones de inclusin estn etiquetadas con el texto <<include>>. Por ejemplo, supongamos que un despachador puede omitir una tecla en cualquier momento para tener acceso a la ayuda. Esto puede modelarse mediante un caso de uso AyudaDespachador que est incluido en los casos de uso AbrirIncidente y AsignarRecursos (y cualesquiera otros casos de uso a los que tenga acceso el despachador). El modelo resultante describe solamente una vez la funcionalidad de AyudaDespachador, reduciendo de esta forma la complejidad.

AbrirIncident e

<<include> > AyudaDespacha dor

AsignarRecurs os

<<include> >

EJEMPLO:

MULTIPLICIDAD Se puede utilizar la misma representacin usada en el diagrama de clases para representar una o ms ocurrencias de la participacin del actor con respecto al caso de uso. Por ejemplo, uno o ms restaurantes pueden participar al mismo tiempo en el cumplimiento de la orden de la misma comida o ms de una orden a la vez.

14
INVESTIGACIN INDIVIDUAL. Elaborar investigacin en el cuaderno de tareas. 1. Para qu sirven los Casos de Uso? 2. Menciona los requerimientos para el Diagrama de Caso de Uso. EJEMPLO: Elabore usando el software de UML el Diagrama de Casos de Uso del siguiente sistema: (Abajo se presentan dos posibles soluciones, analcelas y diagrmelas) Completar el listado con las notas de los alumnos Agregar y eliminar un alumno del listado Integrar los listados de varios grupos de una misma asignatura en un solo listado Otras opciones que se le exige a la aplicacin, para satisfacer completamente las necesidades del docente , son las siguientes: Permitir la consulta de la siguiente informacin de cualquier alumno seleccionado:Carn, Apellidos, Nombres, Lista de asignaturas en las que est inscrito el alumno (cdigo de la asignatura, nombre de la asignatura) Obtener una estadstica de las notas obtenidas por los alumnos en un determinado grupo de un asignatura. En esta estadstica se tendr de cada posible nota: Nmero de alumnos con esa calificacin, porcentaje sobre el total del grupo. Consultar porcentaje de personas sobre el total del grupo que se han presentado y el de los que no se han presentado. Poder visualizar un grfico indicativo del nmero de personas que han obtenido una calificacin entre 0.99, 1.00 1.99, 2.00 2.99, 3.00 3.99, 4.00 4.99, 5.00 5.99, 6.00 6.99, 8.00 8.99, 9.00 - 10.00; indicndose la nota media obtenida por la clase. Disponer de una calculadora que permita realizar las operaciones de suma, resta, multiplicacin, divisin. Esta calculadora se activar cuando se vayan a introducir las notas a algn alumno de forma que una vez realizada la operacin aritmtica, pulsando un botn se coloque el resultado en la casilla donde se estn introduciendo las notas, redondendose a dos cifras decimales. Permitir la importacin y exportacin de la lista de alumnos con sus notas a un formato compatible con MS Excel. Imprimir las listas completas o parciales de notas. Finalmente, como una utilidad extra, a la cual slo podr acceder quien se identifique inicialmente como administrador acadmico, se debe permitir:

15

acadmico; adems, se puede inscribir el alumno en una asignatura y en un grupo.

universidad, y cada carrera est formada por los datos de ao, ciclo, asignaturas obligatorias, asignaturas electivas, prerequisitos de cada asignatura.

valorativas por asignatura, y el total de unidades valorativas exigidas por la carrera. los que se puede consultar el nmero mximo de alumnos permitidos, el horario y el docente. Solucin 1 al Ejemplo Actor: Docente: - Registrar notas Calcular nota _ Sumar nota _ Restar nota _ Multiplicar nota _ Dividir nota _ Redondear nota

-Gestionar alumnos en listado Agregar alumno al listado Eliminar alumno del listado Consultar alumno del listado -Integrar grupos (listado de asignaturas) -Importar listados de cada grupo de una asignatura desde el formato MS Excel -Exportar listados de cada grupo de una asignatura a formato MS Excel -Consultar estadstica de alumnos por grupo -Consultar porcentajes de alumnos que asistieron y no asistieron a la evaluacin -Visualizar grfico de cantidad de alumnos con notas entre rangos de notas -Imprimir listados Imprimir listados finales (completos) Imprimir listados parciales

16
-Validar usuario Solucin 2 al Ejemplo Actor: Administrador Acadmico: -Gestionar alumno Agregar alumno -Inscribir alumno Modificar alumno -Gestionar asignatura Eliminar alumno -Validar usuario (el mismo del actor Docente) Consultar historial acadmico del alumno -Gestionar grupo -Gestionar carrera

Figura 1. (Solucin 1 del ejemplo)

17
Figura 1. (Solucin 2 del ejemplo)

Para describir un caso de uso utilizamos una plantilla compuesta de 6 campos: El nombre del caso de uso es nico en todo el sistema para que los desarrolladores (y participantes en el proyecto) puedan hacer referencia al caso de uso sin ambigedad. Los actores participantes (principales y secundarios) son los actores que interactan con el caso de uso. Las condiciones iniciales (o precondiciones) describen las condiciones que necesitan satisfacerse antes de que se inicie el caso de uso. El flujo de eventos describe la secuencia de acciones del caso de uso y estarn numeradas para su referencia. El caso comn (es decir, los casos que suceden con frecuencia) y los casos excepcionales (es decir, casos que ocurren rara vez, como los errores y condiciones inusuales) se describen por separado en diferentes casos de uso para efectos de claridad. Las condiciones de salida (o post condiciones) describen las condiciones que se satisfacen despus que se termina el caso de uso. Los requerimientos especiales (o flujos alternativos) son aquellos que no estn relacionados con la funcionalidad del sistema. Incluyen restricciones sobre el desempeo del sistema, su implementacin, las plataformas de hardware en las que se ejecuta, etc. A esta plantilla se le conoce como Formato Bsico para la Especificacin de Casos de Uso; que es equivalente a un diccionario de datos.