INDICE

INTRODUCCIÓN

El modelo y diseño orientado a objetos u OMT( técnica de modelado de objetos ) se extiende desde el análisis hasta la implementación pasando por el diseño . Actualmente es una de las metodologías mas implantadas.

Las técnicas 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 sub-subpartes,etc.

La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que esté basada esta metodología. Por eso, este curso revisa los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.

El curso parte dando a conocer la base del diseño y programación de buenas clases, tanto por si solas como a través del uso de herencia. Luego introduce el concepto de subtipos, como concepto teórico que está detrás de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Más tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseño, 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 están bien diseñadas, y en particular si la herencia está bien usada.

Esto es fundamental para que los diseños a objetos no sean más complicados de entender que los de procedimientos y para que el software que se diseñe sea reusable y fácil de extender. Finalmente presenta los aspectos más importantes de la etapa de análisis, dando énfasis a la especificación de casos de uso y a como detectar objetos y clases relevantes en el problema. Durante el curso se usa la notación UML (estándar) y los programas están en C++ o Java. Las clases prácticas son en C++ o Java y se usa una herramienta de apoyo al diseño

REQUERIMIENTOS DEL SISTEMA

Descripción 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 institución 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 evaluación para su aprobación. Adicionalmente necesitan pasar por la aprobación de un responsable en caso de que excedan un monto definido.

Cada pedido puede agrupar como máximo 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 institución en línea, 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 institución 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 autorización correspondiente.

También se desea implementar reportes estadísticos 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 institución

• Actualización amigable de la información del sistema, por ejemplo la actualización de los pedidos.

• Permitir el ingreso de ordenes de compras relacionadas a los pedidos

• Generar reportes estadísticos para medir el volumen de los pedidos recibidos por producto y por área.

• Permitir la administración de usuarios que tengan acceso al sistema

ANÁLISIS DE LA INFORMACIÓN

DIAGRAMA DE CASOS DE USO

Diagrama de Frontera

Diagrama de Formato Expandido

CASO DE USO ADMÓN. DE PEDIDOS

ACTORES:

Administradores, Usuarios, Sistema, Proveedores y Área de compras.

TIPO DE ACTORES: Primarios, Secundarios (Proveedor)

DESCRIPCIÓN:

El usuario hace un pedido por medio del sistema el cual valida si tiene derechos o no para realizar la operación, si los tiene se revisa el stock existente del producto y si ya no hay producto en el almacén se envía la petición 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 envía la OC a compras para aprobar o no el pedido, de aceptarlo, se envía 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 evaluación del pedido, registra orden de compra, procesa reportes e imprime.

Curso Normal de los eventos

Clasificación de los casos de uso

EVALUACIÓN

DIAGRAMA DE INTERACCIÓN DE SECUENCIA

DIAGRAMA DE INTERACCIÓN DE COLABORACIÓN

DIAGRAMA DE CLASES

CONCLUSION

Durante la elaboración de este proyecto nos dimos cuenta de la importancia de la documentación del diseño 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 implementación.

Desde el principio del curso tuvimos que acostumbrarnos a la idea de que el diseño orientado a objetos es algo totalmente distinto a la programación estructurada y que tendríamos que romper cualquier esquema y enseñanza previa si deseamos incursionar en leguajes y documentación orientada a objetos

Para el proyecto en particular, observamos que es importante detectar que objetos tendrán ciertas características en particular, por ejemplo, información con protección y la información pública y que probablemente usaremos en otra parte del sistema; la que no necesita restricciones, etc.

Finalmente, constatamos que la representación visual de un sistema puede cristalizar los procesos o transformaciones que sufren los datos, entradas y salidas, y el flujo de datos a través de la organización de forma útil, sobretodo en una metodología orientada a objetos, la cual necesita de una abstracción particular por parte del diseñador.