ANALISI DEL PROBLEMA POR EQUIPO

l Qué es lo que hace?
Lo que toda farmacia realiza venta y compra de medicamentos.


l ¿cómo se hace?
Vendemos medicamentos, conforme lo receten los doctores ya que va contra nuestra etica vender cierto tipos de medicamentos sin receta medica, tambien llevamos un control de las ventas, mediante apuntes en libretas de ventas asi como la entrada y salida de medicamentos de nuestros proveedores.


l ¿con qué frecuencia se presenta?
Pues la venta de medicamentos se realiza a agranel generalmente todo el dia pero en excesivamente en las tardes, por lo cual es muy difícil llevar un control de las ventas ya que se realizan anotaciones en cuadernos. Mientras que la compra de medicamentos se realiza cada semana o cada vez que sea necesario.


l ¿Qué tan grande es el volumen de transacciones o de decisiones?
El volumen de ventas es muy grande como para seguir registrando las ventas en libretas, como lo es tambien la toma de decisiones ya que es una gran cantidad de dinero.


l ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
No es lo deseado, ya que, al hacer cuentas los resultados no son los esperados ya que algunas veces hace falta dinero y no se ve los ingresos a la farmacia.


l ¿Existe algún problema?
Si, no se lleva un buen registro de los medicamentos, ni de las ventas y eso afecta a las utilidades de la farmacia


l si existe un problema, ¿qué tan serio es?
Es serio ya que al no haber utilidades no se puede dar un buen sueldo al personal que labora y no se pueden hacer mas compras de medicamentos.


l si existe un problema, ¿cuál es la causa que lo origina?
Creo que lo origina la falta de automatización en la farmacia y falta de organización por parte del administrador.


PROBLEMÁTICA DE LA FARMACIA

Al no haber automatización no se obtienen los resultados esperados por el cliente, por lo cual ha habido perdidas en estos ultimos meses, y no ha resultado terner la cantidad de empleados que tiene, ya que no se han obtenido las utilidades esperadas por el cliente.



POSIBLES SOLUCIONES

La compra o utilización de equipos de computo de ultima generacion.

La implementacion de un software que pueda automatizar los procesos de ventas asi como los de entrada y salida de medicamentos.

Capacitacion al personal para el uso de equipos de computo asi como la capacitacion para el uso del software que deba implementarse.



FACTIBILIDAD


TECNICA: No cuento con los equipos de computo, pero si cuento con el personal para que se capacite y pueda hacer uso de los equipos que deban comprase, y si se pude realizar con la tecnología de software actual la aplicación que necesito.


ECONOMICA: Al realizarse la aplicación que necesito habria una mejor organización de ventas, por lo tanto no habrian perdidas de dinero, y los beneficos obtenidos serian mayores a los que hay ahora.


OPERACIONAL: Si se implementara el uso de una aplicación para la realización de nuestras actividades seria usada al 100% ya que facilitaria el trabajo de los empleados.



OBJETIVOS

GENERALES:
Registrar las ventas de medicamentos y control de entrada y salida de los medicamentos de los distintos proveedores.

ESPECÍFICOS:

Necesito un registro de las ventas de cada dia asi como el total de utilidades , al igual que un inventario de todos los medicamentos y quien es el proveedor, asi como una lista de los medicamentos prontos a caducar.

OBJETOS

Empleado:
Atributos:
------------------------------
Nombre
Edad
Sexo
Direccion
Credencial de elector
Curp
Telefono
Turno
Salario
Area
Numero_empleado
------------------------------
Vende los medicamentos
Realiza limpieza
Registra medicamentos en el inventario
Hace pedidos de medicamentos a los proveedores

Producto:
Atributos:
------------------------------
Nombre
Fecha_caducidad
Precio_compra
Precio_ venta
Nombre_laboratorio
Tipo
Fecha_venta
No_pedido
------------------------------
Es vendido
Es comprado
Se registra en el inventario
Se oferta

Cliente
Atributos:
------------------------------
Nombre
RFC
Direccion
Telefono
Forma_pago
------------------------------
Compra medicamentos y los utiliza según su receta medica

Proveedor
Atributos:
------------------------------
Nombre
RFC
Direccion
Telefono
Medicamento_vendido
------------------------------
Provee de medicamentos a la farmacia
Factura los medicamentos

DIAGRAMA DE COLABORACION

Introduccion al diseño de la solucion

Define la estructura del sistema: -qué componentes existen - qué papel juega cada componente - cómo se relacionan los componentes. Justifica las decisiones de diseño Emplea diagramas y notaciones formales. Debe acomodar cambios (se producirán) Independiente del lenguaje, el S.O.

Analisis

IDENTIFICAR METODOS EN LOS OBJETOS

Pueden ser clasificados entre tres grandes categorías:
• Operaciones que manipulan datos
• Operaciones que realizan algún Calculo
• Operaciones que monitorizan un objeto frente a la ocurrencia de un sistema de control

El ciclo de vida de un objeto puede resumirse de la siguiente manera:
• Crear el objeto
• Modificarlo • Manipulación
• Borrar Las actividades conocidas que ocurren durante su ciclo de vida son:
• Asignación de Tarea
• Panel de control
• Alarma audible

ESTUDIO DE FACTIBILIDAD : Factibilidad Económica Se refiere a los gastos que pueda generar durante el desarrollo del sistema, el cual se traduce principalmente en gastos de papelería (cintas de impresoras, fotocopias, hojas blancas, encuadernación, entre otros) y otros gastos como energía eléctrica e Internet mostrada en la tabla número 2; Hay que destacar que esta investigación no busca ninguna renumeración o beneficio económico.

PCSOFT: Factibilidad Operativa El sistema PCSOFT podrá ser utilizado por cualquier persona que sepa manejar un computador y este interesado por el tema.

CRONOGRAMA DE ACTIVIDADES: El siguiente cronograma está basado en el diagrama de Gantt, referenciado por Senn (1989). Este diagrama consiste en un gráfico de barras donde las ordenadas representan las actividades y las abscisas el tiempo, representado en meses. La línea punteada de la gráfica indica la fase actual del desarrollo del sistema.

Analisis

IDENTIFICAR ATRIBUTOS DE LOS OBJETOS

En esencia, son los atributos los que definen al objeto, los que clarifican lo que representa el objeto en el contexto del espacio del problema. Por ejemplo, si se tratara de construir un sistema de estadísticas para jugadores profesionales de béisbol, los atributos del objeto Jugador serían muy diferentes de los atributos del mismo objeto cuando se use dentro del contexto de un sistema de pensiones para jugadores profesionales. En el primero, atributos tales como nombre, posición, promedio de bateo, porcentaje de estancia en el campo de juego, años jugados y partidos jugados pueden ser relevantes. En el segundo caso, algunos de estos atributos serían relevantes pero otros serían reemplazados (o potenciados) por atributos como salario medio, crédito total, opciones elegidas para el plan de pensión, dirección postal, etc. Para desarrollar un conjunto significativo de atributos para un objeto, el analista puede estudiar de nuevo la narrativa del proceso (o descripción del ámbito del alcance) para el problema y seleccionar aquellos elementos que razonablemente “pertenecen” al objeto.

Analisis

DESCUBRIR OBJETOS EN EL DOMINIO DEL PORTAL

En general, un objeto nunca debe tener un “nombre procedimental imperativo”. Coud y Yourdon sugieren seis características de selección a usar cada vez que un analista considera si incluye o no un objeto potencial en el modelo de análisis: o Información retenida el objeto potencial será de utilidad durante el análisis solamente si la información acerca de él debe recordarse para que el sistema funciones. o Servicios necesarios el objeto potencial debe poseer un conjunto de operaciones identificables que pueden cambiar de alguna manera el valor de sus atributos. o Atributos múltiples durante el análisis de requisitos, se debe centrar la atención en la información principal (un objeto con un solo atributo puede, en efecto, ser útil durante el diseño, pero seguramente será mejor presentado como un atributo de otro objeto durante la actividad de análisis). o Atributos comunes puede definirse un conjunto de atributos para el objeto potencial, los cuales son aplicables a todas las ocurrencias del objeto. o Operaciones comunes puede definirse un conjunto de operaciones para el objeto potencial, las cuales son aplicables a todas las ocurrencias del objeto. o Requisitos esenciales entidades externas que aparecen en el espacio del problema y producen o consumen información esencial para la producción de cualquier solución para el sistema, serán casi siempre definidas como objetos en el modelo de requisitos. Para ser considerado un objeto válido a incluir en el modelo de requisitos, un objeto potencial debe satisfacer todas (o casi todas) las características anteriores. La decisión de incluir objetos potenciales en el modelo de análisis es algo subjetivo, y una evaluación posterior puede llegar a descartar un objeto o reincluirlo. Sin embargo, el primer paso del Análisis Orientado a Objetos debe ser la definición de objetos, y la consiguiente toma de decisiones (incluso subjetivas).

Planteamiento del problema

INDETIFICAR FUNCIONES DEL SISTEMA

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. A los operadores por si se presentan mensajes de error, sepan cómo responder a ellos. Además que se encargan de darle soporte técnico al programa. A los programadores a través del manual del analista para que recuerden aspectos de la elaboración del programa o en caso que otras personas puedan actualizarlo o modificarlo (darle mantenimiento) y no son necesariamente las personas que lo diseñaron. Es por ello, que la documentación debe contener algoritmos y flujogramas de los diferentes módulos que lo constituyen y las relaciones que se establecen entre ellos; listados del programa, corridas, descripción de variables que se emplean en cada módulo, cuáles son comunes a diferentes módulos y cuáles locales; descripción de los ficheros de cada módulo y todo lo que sea de importancia para un programador. A los analistas de sistemas que son las personas que deberán proporcionar toda la información al programador. Estos se encargan de hacer una investigación previa de cómo realizar el programa y documentar con las herramientas necesarias para que el programador pueda desarrollar el sistema en algún lenguaje de programación adecuado.

Planteamiento del problema

ANALIZAR EL PROBLEMA ENUNCIADO

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.

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.


UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware,
y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más usadas orientados a objetos.

Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson,
creadores de tres de las metodologías orientadas a objetos más populares.

Extensiones UML :
Los mecanismos de de extensibilidad incorporados permiten a UML ser una especie de especificación abierta que puede cubrir aspectos de modelado estos mecanismos permiten extender la notación y semática de UML.

Extensiones de Modelado de Negocio:
Un documento separado dentro de la especificación UML define clases y estereotipos de asociación específicos que extienden UML hasta cubrir conceptos de modelado de negocio. Esto incluye 'stereotyping' una clase como un actor, un trabajador ('both internal and case'), o una entidad, y 'stereotyping' una asociación como una comunicación simple, o una subcripción entre un origen y un objetivo.

Lenguaje restrictivo (constraint) de objetos (OCL):
Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico puede describir una cierta parte del comportamiento, después de la cual es necesario rellenar detalles adicionales con palabras. Describiendo algo con palabras, sin embargo, casi siempre desemboca en ambiguedades; por ejemplo, "¿que quería decir cuando escribió eso?". El Lenguaje Restrictivo (constraint) de Objetos (OCL) está incorporado en UML como un estándar para especificar detalles adicionales, o precisar detalles en la estrucutura de los modelos.
Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado de negocio, el OCL es un lenguaje formal diseñado para ser fácil de leer y de escribir. OCL es más funcional que el lenguaje natural, pero no tan preciso como un lenguaje de programación - no puede ser usado para escribir lógicas de lógica de programación o control de flujo. Puesto que OCL es un lenguaje para la expresión pura, sus declaraciones están garantizadas de no tener efectos laterales - simplemente transportan un valor y nunca pueden cambiar el estado del sistema.

El Modelo Como Resultado De La Abstraccion

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. El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Principios de Modelado
En cualquier proyecto de ingeniería como la construcción de un gran edificio, un avión, una represa hidroeléctrica, la construcción de un procesador de textos o un software de comunicaciones para Internet, requieren de etapas de modelamiento que permitan experimentar y visualizar el sistema que se construirá. De la experiencia en ingeniería se extractan los siguientes principios de modelado:

a) 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.

b) 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.

c) 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.

d) 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.


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.
El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Definicion De Clases, Atributos, Metodos Y Objetos

Los objetos son entidades que combinan estado, comportamiento e identidad. El estado está compuesto de datos, y el comportamiento por procedimientos o métodos. La identidad es una propiedad de un objeto que lo diferencia del resto. La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutilizar.

Los métodos y atributos están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos. Hacerlo podría resultar en seguir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que la manejen por el otro. De esta manera se estaría llegando a una programación estructurada camuflada en un lenguaje de programación orientado a 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

Tecnicas Basicas De Modelado De Objetos

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.

En si es un conjunto de procesos a seguir que podemos utilizar para la representacion de objetos en el caso que necesitemos como por ejemplo los diagramas UML.