Datos personales

Tuxtla Gutierrez, Chiapas, Mexico

sábado, 17 de noviembre de 2007

2 - Tecnicas Basicas de Modelado de Objetos

Según la Real Lengua Española: Técnica: es Conjunto de procedimientos y recursos de que se sirve una ciencia o un arte. Modelado: es una técnica que ayuda a “visualizar” el sistema a construir. Objeto: Un objeto es una representación detallada, concreta y particular de un “algo”. Tal representación determina su identidad, su estado y su comportamiento particular en un momento dado.
En conclusión es Una serie de procedimientos para visualizar una serie de caracteristicas asignadas a un objeto

2.1- Definicion de Clases Atributos Metodos y Objetos

Es decir, en java las variables de tipo básico son el nombre de una zona de memoria en la cuál podemos almacenar valores, pero que en cambio, las variables de tipo objeto son en realidad referencias (punteros o alias) de objetos.

Una variable de tipo objeto no es un objeto completo, sino tan solo almacena la situación del objeto en la memoria del equipo. Esto es muy similar a lo que ocurre con las casas y las direcciones de dichas casas: la dirección calle Alcalá 950 es una dirección válida, pero no podemos mandar cartas a dicha dirección porque es…un descampado!!!

Lo mismo sucede con los objetos, podemos tener una variable para referirnos a objetos, pero la variable puede que no apunte a ningún objeto y por tanto no la puedo emplear para intentar acceder a un método o a un atributo del objeto referenciado por la variable, sencillamente porque no existe el objeto referenciado.

Una variable que no apunta a un objeto se asume que tiene un valor especial llamado null, e incluso podemos asignar el valor null a la variable:

Thread t = null;

Es por ello que se deben construir objetos y asignárselos a las referencias, usando la palabra clave new. new permite crear un objeto a partir de la descripción de la clase que le pasamos como argumento, por ejempo:

new Persona()

Conseguimos crear un objeto de la clase Persona, los paréntesis permiten especificar qué constructor estamos llamando al crear el objeto (veremos constructores más adelante).

Pero al crear un objeto persona como en el código anterior lo estamos creando como un objeto anónimo, es decir sin asignar el objeto a una variable de tipo referencia, desde la cuál poder referirnos al objeto y poder llamar a sus métodos y atributo, por ello lo más habitual será asignar el objeto a una variable como en: 0359

2.2 - El Modelo como resultado de la Abstraccion

En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.

La forma como vemos el problema tiene una profunda influencia en forma como acometemos el problema y le damos solución al mismo. Si pensamos que el mundo esta compuesto de clases (Abstracciones de la realidad y de la solución del problema) y objetos (instancias de éstas abstracciones) que interactúan entre si para realizar una funcionalidad, así veremos el mundo. Este es precisamente al paradigma a que le apuesta UML: el modelo orientado a objetos. Si vemos la realidad como compuesta de procesos donde cada uno a su vez se puede descomponer en subprocesos entonces estamos concibiendo la realidad según el modelo estructurado y la arquitectura del sistema en desarrollo estará conformada de programas y subprogramas.
  1. Para modelar un sistema complejo no es suficiente un único modelo se requieren múltiples modelos donde cada uno representa una vista (aspecto) del sistema; estos modelos se complementan entre si. Esta es la razón de la existencia de varios diagramas en UML que modelan diferentes aspectos del sistema, desde las vistas lógicas y físicas del sistema hasta los aspectos dinámicos, estáticos y funcionales del mismo.
  2. Cualquier modelo puede ser representado con diferentes grados de precisión. La precisión se puede ver desde dos ópticas: La primera es el grado de detalle con que se representa un modelo; por ejemplo, si lo que se desea es razonar acerca de los requerimientos del sistema con un cliente o usuario final, se puede elaborar un diagrama de clases que muestra las clases, sus atributos y operaciones así como varios adornos(multiplicidad) en las relaciones; por otro lado, si lo que se desea es transmitir el diagrama de clases para que sea implementado en un DBMS (Data Base Management System, Sistema Administrador de Bases de Datos) por un programador, el diagrama con toda seguridad contendrá la visibilidad de las características (atributos y operaciones) de las clases, los tipos de datos de los atributos y las signaturas de las métodos de las clases. La segunda forma de ver la precisión de un modelo se refiere al nivel de abstracción, ese decir, a los detalles y la vista (porción del sistema o realidad) que presenta un modelo al lector; por ejemplo, en un sistema Bancario que maneja los retiros que hacen los clientes ya sea en un cajero automático o humano, el diagrama de clases contiene decenas de éstas; sin embargo las personas encargadas de desarrollar la interfaz de un cajero electrónico estarían interesadas en las clases necesarias para realizar el comportamiento del cajero y omiten el resto de clases del sistema.
  3. Los mejores Modelos están ligados a la realidad. El símbolo de un actor en un diagrama de casos de uso representa, de hecho, un actor en el sistema real; así como un componente en un diagrama de componentes representa un componente físico del software. Cada elemento de UML como una clase, objeto, estado, componente o nodo tiene su correspondencia con algún elemento conceptual o físico del mundo real.

2.3 - El Uml como una Herramienta de Modelado de Objetos

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.
Casos de Uso (Use Case) El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.
Elementos
Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.
Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.
Relaciones:
  1. Asociación
  2. Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
  3. Dependencia o Instanciación
  4. Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
  5. Generalización
  6. Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso («uses») o de Herencia («extends»).
  7. Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
  8. extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).
  9. uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
  10. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

lunes, 12 de noviembre de 2007

2.4 - Planteamiento del problema.


Aquí es en donde se basa toda la parte fundamental de la estructuración del proyecto a realizar, porque es aquí donde se define y tienen en cuentan todos los aspectos y puntos que el programa debe de cubrir para satisfacción del cliente y su implementación del software.

Por eso a continuación de los pasos 2.4.1 y 2.4.2 se definen y se trata de adaptar la problemática que nosotros decidimos tomar para poder desempeñar nuestros conocimientos como desarrolladores e interpretación de la problemática del cliente al estado del software.
Como forma general el planteamiento de un problema es cuando nos dan el problema en concreto, sin indagar mucho a fondo y sin tener punto de apoyo o sencilla explicaciones del cliente para poder complente aun mejor la problematica, en nuestro caso se nos dice que quieren implementar un software para el control de inventario y cobranza de la boutique.

2.4.1. - Analizar El Enunciado Del Problema

El análisis comienza con la definición de un problema generada por clientes y, posiblemente, por los desarrolladores. El análisis hace que sea más precisa y expone las ambigüedades e incongruencias y no debería tomarse como inmutable, sino que tiene que servir como base para refinar los requisitos reales. El analista debe ser para los requisitos verdaderos de las decisiones del diseño y de implementación disfrazada de requisitos y atacar a estos pseudorequisitos, porque restringen la flexibilidad. El propósito del análisis subsiguiente es comprender en su totalidad el problema y sus implicaciones.
Problematica del equipo.
La problemaitca que se trabaja aqui es que no se lleva un control muy eficaz, de las piezas vendidas, las piezas apartadas, y las que son vendidas a pagos. Además se tiene un problema de llevar un registro de los accesorios y regalos que se venden por separado. Cabe mencionar que en estos cortes de caja se debe descontar el sueldo del empleado y no se hace de manera rápida.

Por lo cual el cliente nos dice que necesita un programa capaz de registrar un inventario total de la boutique, llevar apartados, crédito y ventas en efectivo. Todo esto mas, la extensión de un comprobante de pagos, ya fuese a contado o crédito.

2.4.2 - Identificar Funciones Del Sistema


Consiste en describir por escrito a nivel técnico los procedimientos relacionados con el programa y su modo de uso. También se debe documentar el programa para que sea más entendible.

¿Para quiénes son la documentación?

- Usuarios (Digitadores)
- Operadores
-Programadores
- Analistas de sistemas

Documentos que se elaboran: Manual de Usuario y Manual del Analista. A los usuarios se les elabora un manual de referencia para que aprendan a utilizar el programa. Esto se hace a través de capacitaciones y revisión de la documentación del manual de usuario. El manual del usuario no está escrito a nivel técnico sino al de los distintos usuarios previstos y explica en detalle cómo usar el programa: descripción de las tareas que realiza el programa, instrucciones necesarias para su instalación puesta en marcha y funcionamiento, recomendaciones de uso, menús de opciones, método de entrada y salida de datos, mensajes de error, recuperación de errores, etc.
Por no tener desarrollado el software no podemos escribir o llevar acabo este procedimiento, o en su caso hacerlo posible para nuestra problematica.