You are on page 1of 8

INDICE INTRODUCCIN El modelo y diseo orientado a objetos u OMT( tcnica de modelado de objetos ) se extiende desde el anlisis hasta la implementacin

pasando por el diseo . Actualmente es una de las metodologas mas implantadas. Las tcnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento especifico. Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes , subpartes y subsubpartes,etc. La metodologa de desarrollo de software orientada a objetos es cada da ms usada, pues permite desarrollar software fcilmente extensible y reusable. Esto ltimo es slo posible si los desarrolladores conocen muy bien los fundamentos que est basada esta metodologa. Por eso, este curso revisa los conceptos ms importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos. El curso parte dando a conocer la base del diseo y programacin de buenas clases, tanto por si solas como a travs del uso de herencia. Luego introduce el concepto de subtipos, como concepto terico que est detrs de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Ms tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseo, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, provee mecanismos para verificar si una clase y las relaciones entre ellas estn bien diseadas, y en particular si la herencia est bien usada. Esto es fundamental para que los diseos a objetos no sean ms complicados de entender que los de procedimientos y para que el software que se disee sea reusable y fcil de extender. Finalmente presenta los aspectos ms importantes de la etapa de anlisis, dando nfasis a la especificacin de casos de uso y a como detectar objetos y clases relevantes en el problema. Durante el curso se usa la notacin UML (estndar) y los programas estn en C++ o Java. Las clases prcticas son en C++ o Java y se usa una herramienta de apoyo al diseo REQUERIMIENTOS DEL SISTEMA Descripcin del caso SISTEMA DE COMPRAS DEL COLEGIO BIONIC Antecedentes El colegio Bionic brinda servicios educativos de nivel medio superior a aproximadamente 2000 alumnos y cuenta con los servicios de 100 empelados entre docentes y personal administrativo. Actualmente las distintas reas de la institucin hacen llegar sus pedidos al rea de compras mediante formatos impresos, en tanto los productos solicitados se encuentren en el stock se proceder despacharlos al rea solicitante. En caso contrario estos pedidos pasan una evaluacin para su aprobacin. Adicionalmente necesitan pasar por la aprobacin de un responsable en caso de que excedan un monto definido. Cada pedido puede agrupar como mximo 10 productos. Una vez que el producto es aprobado se procede a generar las ordenes de compra a los proveedores, los que son registrados manualmente.

Objetivos del sistema El objetivo es que el rea de compras reciba los pedios de las diferentes reas de la institucin en lnea, los que ser evaluados y calificados para que luego se les pueda hacer el seguimiento. Una vez evaluados el sistema deber permitir el registro de las ordenes de compra que se hayan generado para atender algunos de los pedidos recibidos. De este modo se podr tener el ahorro de tiempo y dinero que la institucin est buscando. Adicionalmente el sistema debe controlar que el acceso al sistema y las acciones que en l se ejecuten sean realizados por personas que cuenten con la autorizacin correspondiente. Tambin se desea implementar reportes estadsticos que permitan medir el volumen de pedidos recibidos por producto y por rea solicitante. Requerimientos del sistema de compras Validar el acceso al sistema Contar con roles predefinidos para restringir el acceso de ciertas opciones a algunos usuarios Permitir el ingreso de pedidos de productos a las distintas reas de la institucin Actualizacin amigable de la informacin del sistema, por ejemplo la actualizacin de los pedidos. Permitir el ingreso de ordenes de compras relacionadas a los pedidos Generar reportes estadsticos para medir el volumen de los pedidos recibidos por producto y por rea. Permitir la administracin de usuarios que tengan acceso al sistema ANLISIS DE LA INFORMACIN DIAGRAMA DE CASOS DE USO Diagrama de Frontera

Diagrama de Formato Expandido CASO DE USO ADMN. DE PEDIDOS ACTORES: Administradores, Usuarios, Sistema, Proveedores y rea de compras. TIPO DE ACTORES: Primarios, Secundarios (Proveedor) DESCRIPCIN: El usuario hace un pedido por medio del sistema el cual valida si tiene derechos o no para realizar la operacin, si los tiene se revisa el stock existente del producto y si ya no hay producto en el almacn se enva la peticin al evaluador, el cual examina el pedido para que este no exceda en 10 productos emitiendo un fallo favorable o desfavorable. En caso de ser favorable se enva la OC a compras para aprobar o no el pedido, de aceptarlo, se enva la OC al proveedor para que los surta. El usuario puede pedir distintos reportes al sistema. REFERENCIAS CRUZADAS El sistema registra claves de usuario, recibe fallo favorable o desfavorable, recibe evaluacin del pedido, registra orden de compra, procesa reportes e imprime. Curso Normal de los eventos ACCION DEL ACTOR 1. El administrador registra las claves de usuario y asigna roles, con los cuales se podr restringir el acceso al sistema y a distintas opciones de men 2. El usuario hace una solicitud de pedido 4. El almacn revisa las existencias del producto seleccionado y manda su respuesta hacia el sistema 6. El evaluador emite un fallo favorable o desfavorable a cerca del pedido ACCION DEL SISTEMA 2. Guarda las configuraciones 3. El sistema valida la clave y canaliza la opcin hacia el almacn 5. Si existe el producto se procede a enviarlo al usuario que lo solicit, de lo contrario manda el pedido al evaluador 7. El sistema recibe la respuesta del evaluador 8. Si la respuesta del evaluador fue favorable, se enva el pedido a compras 9. Compras examina que el pedido no exceda de 10 productos 12. Compras imprime la OC y se la manda al proveedor 13. El usuario elige la opcin reportes, dentro del men que fue personalizado por el administrador 10. Recibe la respuesta de compras 11. Si se admiti el pedido, enva la OC a Compras

14. Procesa la informacin y la imprime para el usuario

Clasificacin de los casos de uso Tener una fuerte repercusin en el diseo arquitectnico, por ejemplo incorporar muchas clases a la capa del domino o requerir servicios de persistencia Con relativo poco esfuerzo se obtiene informacin e ideas importantes sobre el diseo Incluir funciones riesgosas complejas o urgentes Requerir una investigacin a fondo o tecnologa nueva Representar procesos primarios de la lnea del negocio Apoyar directamente el aumento de ingresos o la reduccin de costos EVALUACIN Nada Poco Mucho NOMBRE DEL CASO DE USO A 1. Registra usuario, claves y asignar roles 3 2. Solicitar pedido 2 3. Revisa existencias 1 4. Emite fallo 2 5. Enva pedido 2 6. Evala pedido 2 7. Registra Orden de Compra 2 8. Enva Orden de Compra 1 9. Elige opcin reportes 1 10. Procesa informacin e imprime 1 DIAGRAMA DE INTERACCIN DE SECUENCIA B 2 2 1 2 1 1 1 1 1 1 C 3 1 1 2 2 2 2 2 1 1 D 1 1 1 2 1 1 2 1 1 1 E 1 1 1 1 1 1 1 1 1 1 F 3 3 3 3 3 3 3 3 1 1 TOTAL 13 10 8 12 10 10 11 9 6 6

DIAGRAMA DE INTERACCIN DE COLABORACIN

DIAGRAMA DE CLASES

CONCLUSION Durante la elaboracin de este proyecto nos dimos cuenta de la importancia de la documentacin del diseo de un sistema, y que algunas veces este proceso se omite pues resulta ser un poco tedioso, sin embargo es fundamental para el desarrollo de un sistema y su posterior implementacin. Desde el principio del curso tuvimos que acostumbrarnos a la idea de que el diseo orientado a objetos es algo totalmente distinto a la programacin estructurada y que tendramos que romper cualquier esquema y enseanza previa si deseamos incursionar en leguajes y documentacin orientada a objetos Para el proyecto en particular, observamos que es importante detectar que objetos tendrn ciertas caractersticas en particular, por ejemplo, informacin con proteccin y la informacin pblica y que probablemente usaremos en otra parte del sistema; la que no necesita restricciones, etc. Finalmente, constatamos que la representacin visual de un sistema puede cristalizar los procesos o transformaciones que sufren los datos, entradas y salidas, y el flujo de datos a travs de la organizacin de forma til, sobretodo en una metodologa orientada a objetos, la cual necesita de una abstraccin particular por parte del diseador.

You might also like