Metodología de análisis y diseño orientado a objetos

Informática. Computación. Requerimientos del sistema. Objetivos. Análisis de la información. Diagramas. Interacción de secuencia. Colaboración. Clases

  • Enviado por: Ratiux
  • Idioma: castellano
  • País: México México
  • 11 páginas
publicidad
cursos destacados
Apps en HTML5 para BlackBerry 10
Apps en HTML5 para BlackBerry 10
Este curso te guiará en el desarrollo de una app completa para BlackBerry 10, paso a paso. La app que desarrollaremos...
Ver más información

Crea aplicaciones para Android sin programar
Crea aplicaciones para Android sin programar
El mercado de aplicaciones móviles está en constante crecimiento y es Android el sistema operativo que lo está...
Ver más información

publicidad

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

'Metodología de análisis y diseño orientado a objetos'

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

ACCION DEL ACTOR

ACCION DEL SISTEMA

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. Guarda las configuraciones

2. El usuario hace una solicitud de pedido

3. El sistema valida la clave y canaliza la opción hacia el almacén

4. El almacén revisa las existencias del producto seleccionado y manda su respuesta hacia el sistema

5. Si existe el producto se procede a enviarlo al usuario que lo solicitó, de lo contrario manda el pedido al evaluador

6. El evaluador emite un fallo favorable o desfavorable a cerca del pedido

7. El sistema recibe la respuesta del evaluador

8. Si la respuesta del evaluador fue favorable, se envía el pedido a compras

9. Compras examina que el pedido no exceda de 10 productos

10. Recibe la respuesta de compras

11. Si se admitió el pedido, envía la OC a Compras

12. Compras imprime la OC y se la manda al proveedor

13. El usuario elige la opción reportes, dentro del menú que fue personalizado por el administrador

14. Procesa la información y la imprime para el usuario

Clasificación de los casos de uso

  • Tener una fuerte repercusión en el diseño arquitectónico, por ejemplo incorporar muchas clases a la capa del domino o requerir servicios de persistencia

  • Con relativo poco esfuerzo se obtiene información e ideas importantes sobre el diseño

  • Incluir funciones riesgosas complejas o urgentes

  • Requerir una investigación a fondo o tecnología nueva

  • Representar procesos primarios de la línea del negocio

  • Apoyar directamente el aumento de ingresos o la reducción de costos

  • EVALUACIÓN

  • Nada

  • Poco

  • Mucho

  • NOMBRE DEL CASO DE USO

    A

    B

    C

    D

    E

    F

    TOTAL

    1. Registra usuario, claves y asignar roles

    3

    2

    3

    1

    1

    3

    13

    2. Solicitar pedido

    2

    2

    1

    1

    1

    3

    10

    3. Revisa existencias

    1

    1

    1

    1

    1

    3

    8

    4. Emite fallo

    2

    2

    2

    2

    1

    3

    12

    5. Envía pedido

    2

    1

    2

    1

    1

    3

    10

    6. Evalúa pedido

    2

    1

    2

    1

    1

    3

    10

    7. Registra Orden de Compra

    2

    1

    2

    2

    1

    3

    11

    8. Envía Orden de Compra

    1

    1

    2

    1

    1

    3

    9

    9. Elige opción reportes

    1

    1

    1

    1

    1

    1

    6

    10. Procesa información e imprime

    1

    1

    1

    1

    1

    1

    6

    DIAGRAMA DE INTERACCIÓN DE SECUENCIA

    'Metodología de análisis y diseño orientado a objetos'

    DIAGRAMA DE INTERACCIÓN DE COLABORACIÓN

    'Metodología de análisis y diseño orientado a objetos'

    DIAGRAMA DE CLASES

    'Metodología de análisis y diseño orientado a objetos'

    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.