Documente Academic
Documente Profesional
Documente Cultură
Trabajo de programación IV
Tema
PROYECTO #1
Profesor:
Diego Santimateo G.
Integrantes:
Fecha:
Septiembre 26 de 2008
Índice
Introducción…………………………………………….……….……...3
Objetivos…………………………………………………………….… 4
Entrevista……………………………………………………….……….6
Utilidad de la información……………………………………………..9
Glosario…………………………………………………………….…..12
Diagrama UML…………………………………………………………17
Síntesis………………………………………………………………….19
Reflexiones……………………………………………………………..35
Conclusión……………………………..……………………………….40
2
INTRODUCCIÓN.
Básicamente, los resultados obtenidos durante el análisis orientado a objetos sirven como
modelo o punto de partida para realizar el diseño del sistema, entonces podremos contar
con creaciones más eficientes, que acentúen su funcionalidad y minimicen el problema.
3
Objetivos
-Objetivos Específicos
•Explorar y analizar información sobre la fase de análisis de sistemas.
•Organizar entrevistas para conocer especialistas que proporcionen información
sobre el dominio donde se desarrollará el Sistema.
•Desarrollar el análisis y diseño OO basados en las distintas etapas que le
conforman.
•Diseñar modelos UML del dominio del problema basado en la metodología de
desarrollo de sistemas (POO).
4
2. ORGANIZACIÓN DE LOS DATOS RECABADOS DE LA ENTREVISTA
Como parte de la primera etapa (análisis OO), hemos organizado una entrevista
con el objetivo de conocer documentos e informes utilizados en un sistema de
administración de inventario.
La entrevista fue realizada a la empresa Junior Internet ubicada en calle 8va, donde
se consulto con la persona encargada de llevar el control administrativo, en este caso con
el dueño de la empresa el Sr. Jorge Luis Espinosa.
5
Entrevista
6
Costo promedio ponderado
Costo de primeras entradas, primeras salidas (PEPS).
Costo de últimas entradas, primeras salidas (UEPS).
7
13¿Cómo le gustaría que se dieran los informes finales del inventario ?
R/.
Diarios, mensuales, Ganancias, Gastos por departamentos de una forma grafica.
8
Utilidad de la información
La información obtenida hasta el momento nos servirá como base para el diseño
de un modelo conceptual que represente los conceptos más importantes del dominio
para el que se desarrolla la propuesta UML.
9
10
DESCRIPCIÓN DEL PROBLEMA O DOMINIO
Planeamientos de la entrevista
11
ANALISIS ORIENTADO A OBJETOS APLICANDO EL
MODELO SEGÚN MIGUEL AVIAN
GLOSARIO
Compra: Es la adquisición de un activo fijo por el cual se origina una obligación de pago.
Las compras de activos fijos se efectúan utilizando el procedimiento establecido con la
referente a las Solicitudes de Autorización de Inversiones.
Compras: El costo de las mercancías que compra una empresa para revenderlas a los
clientes en el curso normal de los negocios.
Costo: Es la magnitud de los recursos, materiales laborales y monetarios necesarios para
alcanzar un cierto volumen de producción con una determinada calidad.
Costo promedio ponderado: método de valuación para el inventario, el costo promedio
ponderado, se calcula dividiendo el costo total de la mercancía disponible para la venta
entre el número de unidades disponibles para la venta.
Costo unitario: Puede medirse en función de su producción y distribución. Este costo es
el que sirve para valuar las existencias que aparecen en el balance general y estado de
pérdidas y ganancias en los renglones de los inventarios de producción en proceso y
productos terminados. También puede medirse en relación con la posibilidad de aplicar
directa o indirectamente a la unidad los gastos incurridos.
Cuentas: El registro detallado de los cambios que han ocurrido en un activo, un pasivo o
en la participación en el capital del propietario en particular durante un período. Un
registro utilizado para resumir todos los aumentos y disminuciones en un activo
determinado, como por ejemplo efectivo, inventarios o cualquier otro tipo de activo, pasivo
o patrimonio, ingreso o gasto.
Hoja de datos: Un documento estructurado en columnas creado para ayudar la
transferencia de información de los estados financieros. Es una hoja de columnas
diseñada para colocar en forma conveniente todos los datos contables que se necesitan
al final del período.
Informe: Exposición, generalmente escrita, sobre un asunto o persona, en el que se
aportan datos y valoraciones para que sea fácil tomar una decisión al respecto. El
resultado de cualquier acción de control.
Inventario: Los inventarios son bienes constituidos por adquisición, en proceso de
elaboración o terminados, bien sean para consumo o para su comercialización.
Inventario perpetuo o continuo: También conocido como sistema de pedido de intervalo
variable. Sistema de control de inventario y reabastecimiento en el cual los niveles de
12
existencias son revisados constantemente y los pedidos se hacen cuando la existencia
baja o supera un nivel predeterminado. En este sistema los reabastecimientos se hacen
generalmente por cantidades estándares pero no se llevan a cabo en fechas establecidas
de antemano.
Inventario periódico: También conocido como sistema de pedidos de intervalos fijos
Sistema de control de inventarios y reabastecimientos en el cual se revisan los niveles de
existencias a intervalos de tiempo predeterminados y los pedidos se basan en los niveles
actuales de existencias, el nivel de reserva de emergencia y un máximo establecido.
Mediante este método el reabastecimiento se hace sobre una base preestablecida, es
decir, en una fecha fija. Sin embargo, la cantidad del pedido puede variar en cada
ocasión.
Producto: valor recibido de la venta de un documento por cobrar antes de la fecha de
vencimiento. El valor al vencimiento menos el descuento es igual al producto.
Tarjetario: Tarjeta donde se escribe el control de entrada y salida de los artículos
adquiridos o vendidos por la empresa. Es usada cuando la empresa utiliza un sistema de
inventario manual.
Venta: Constituye la entrega de un activo fijo a otra entidad creando un derecho de cobro
y por ende cambio de propiedad. En tales casos el modelo de Movimiento debe estar
soportado por la factura correspondiente, con la debida autorización del funcionario
facultado para ello en el nivel superior que corresponda, donde se especifiquen las
condiciones y forma de pago.
13
Identificación de las clases del dominio
Extraeremos las clases de la descripción del problema y de las entrevistas
realizadas a especialistas en el dominio.
14
Descripción Breve el funcionamiento de las clases Utilizadas en el Sistema de Inventario.
15
Clases Atributos Funcionalidad de los métodos
:
captura( ):captura los datos o
mensajes necesarios para el
Class -------------- funcionamiento del sistema.
Funciones despliega( ): despliega los
datos, mensajes necesarios.
suma(): realiza la suma de
diferentes cantidades.
Relaciones entre las Clases:
• Articulo tiene Ventas.
• Articulo tiene Proveedor.
• Compras se hacen a un proveedor.
• Ventas tiene Descripción de Articulo.
• Proveedores venden Artículos.
• Compra Necesita de Artículos.
Venden
Tienen Se hacen a
Descripci de
Class Compra
Necesita
16
Identificación de los atributos y propiedades de las clases
En esta etapa se identifican los atributos y propiedades que tendrán las clases,
como sabemos los atributos o características de una Clase pueden ser de tres tipos,
mediante
Diagrama UML
(Organización de las clases- incluye: Nombre de la clase, atributos y métodos)
Class Compras;
Class Articulo; Class Proveedor;
Class Ventas; Proveedor;
Nombre; Nombre;
Clientes; ; Precio de la
; Código; ; Código;
; Precio de la Venta; compra;
; Cantidad; ; Articulo;
; Cantidad; ; Cantidad;
; Precio Unitario; ; Precio Unitario;
; Precio Unitario; ; Precio Unitario;
; DescripArt;; ; DescripArt;;
; Nº de Factura;; ; Orden de Compra;
PrecioTotal ( ) ; TotalMerc ( );
TotalVenta( ); ; TotalCompra( );
; CantArt( );
17
Diagrama de Caso de Uso:
Caso de uso: administrador Verificando las el tarjetario con los artículos físicos
Tarjetari En el
o Departamento
verifica compara
Pasa a inventario
Físico
Tarjeta vs
Entrada
Inventario F.
Verifica Refleja
Salidas Margen de
utilidad o
perdida.
18
19
ENOCJAHAZIEL CARRASCO
CLASES
Nombres
Atributos
Métodos
Atributos
Pueden ser de tres tipos
• public : Indica que el atributo será visible tanto dentro como fuera de la clase.
• protected : Indica que el atributo no será accesible desde fuera de la clase, pero si
podrá ser accedido por métodos de la clase además de las subclases que se deri-
ven.
Métodos:
• public (): Indica que el método será visible tanto dentro como fuera de la clase, es
decir, es accesible desde todos lados.
• private (): Indica que el método sólo será accesible desde dentro de la clase (sólo
otros métodos de la clase lo pueden acceder).
• protected (): Indica que el método no será accesible desde fuera de la clase, pero
si podrá ser accedido por métodos de la clase además de métodos de las subcla-
ses que se deriven (ver herencia).
RELACIONES
Forma en que se pueden interrelacionar dos o más clases (cada uno con características
y objetivos diferentes).
Herencia
Es una subclase de que hereda los métodos y atributos de una Súper Clase
20
Agregación
Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido
esta condicionado por el tiempo de vida del que lo incluye.
Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto in-
cluido es independiente del que lo incluye.
Asociación
La relación entre clases conocida como Asociación, permite asociar objetos que colaboran
entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un
objeto no depende del otro.
Dependencia
Representa un tipo de relación muy particular, en la que una clase es instanciada (su ins-
tanciación es dependiente de otro objeto/clase). El uso más particular de este tipo de rela-
ción es para denotar la dependencia que tiene una clase de otra
CASOS PARTICULARES
Clase Abstracta
Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itáli-
ca". Esto indica que la clase definida no puede ser instanciada pues posee métodos abs-
tractos
Clase parametrizada
21
Diagrama de interacción
Elementos
Objetos o Actor
Se representa por una flecha entre un objeto y otro, representa la llamada de un método a
otro de un objeto en particular.
22
Hernán Franco G.
1. Modelos
Un modelo representa a un sistema software desde una perspectiva específica.
Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura Estática.
• Diagrama de Casos de Uso.
• Diagrama de Secuencia.
• Diagrama de Colaboración.
• Diagrama de Estados.
2. Elementos Comunes a Todos los Diagramas
2.1 Notas
Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama.
2.2 Dependencias
Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una
flecha en su extremo.
3 Diagramas de Estructura Estática
Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto Modelos Conceptuales,
como Diagramas de Clases de Diseño
3.1 Clases
Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de
la clase, en la media los atributos y en la inferior las operaciones.
3.2 Objetos
Un objeto se representa de la misma forma que una clase. En el compartimiento superior aparecen el nombre
del objeto junto con el nombre de la clase subrayados.
3.3 Asociaciones
Las asociaciones entre dos clases se representan mediante una línea que las une.
3.3.1 Nombre de la Asociación y Dirección
El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea.
Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin
embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el
consiguiente riesgo de saturación.
3.3.2 Multiplicidad
La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una
clase que pueden tener esa asociación con una instancia de la otra clase.
3.3.3 Roles
Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol.
3.3.4 Agregación
El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el
“todo”.
3.3.5 Clases Asociación
Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la
asociación por medio de una línea a trazos.
3.3.6 Asociaciones N-Arias
En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un
diamante central.
3.3.7 Navegabilidad
"navegar" desde el objeto de la clase origen hasta el objeto de la clase destino.
3.4 Herencia
La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la
clase más general o clase “padre”.
3.5 Elementos Derivados
Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el
modelo, pero que se incluye en el modelo por motivos de claridad o como decisión de diseño.
23
Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.
4.1 Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones
entre casos de uso.
4.1.1 Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol).
4.1.2 Casos de Uso
Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el
sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica.
4.1.3 Relaciones entre Casos de Uso
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin
embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso.
La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el
equipo de desarrollo, el manejo de la documentación de casos de uso.
• Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en
dicho caso base.
• Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales,
dependiendo de ciertos criterios, se va a realizar una interacción adicional.
5 Diagramas de Interacción
En los diagramas de interacción se muestra un patrón de interacción entre objetos.
5.1 Diagrama de Secuencia
Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos.
5.2 Diagrama de Colaboración
Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte
en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere).
En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces
entre los mismos, y con los mensajes que se intercambian dichos objetos.
6 Diagramas de Estado
Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un
objeto a lo largo de su vida, o bien todo el sistema.
7 Modelado Dinámico
7.1 Diagramas De Actividades
Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un sistema:
• Diagramas de secuencia.
• Diagramas de colaboración.
• Diagramas de estados.
• Diagramas de casos de uso.
• Diagramas de actividades.
En este capítulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar
el flujo de control entre actividades. La idea es generar una especie de diagrama Pert. El diagrama de
actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los
anteriores diagramas vistos.
7.2 Contenido del diagrama de actividades
Básicamente un diagrama de actividades contiene:
• Estados de actividad.
• Estados de acción.
• Transiciones.
• Objetos.
7.2.1 Estados de actividad y estados de acción
La idea central es la siguiente: “Un estado que represente una acción es atómico, lo que significa que su
ejecución se puede considerar instantánea y no puede ser interrumpida”.
7.2.2 Transiciones
Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción.
24
7.2.3 Bifurcaciones
Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos alternativos. Para poder
representar dichos caminos alternativos o bifurcación se utilizará como símbolo el rombo. Dicha bifurcación
tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión
booleana que será evaluada una vez al llegar a la bifurcación.
7.2.4 División y unión
UML representa gráficamente el proceso de división, que representa la concurrencia, y el momento de la
unión de nuevo al flujo de control secuencial, por una línea horizontal ancha.
7.2.5 Calles
Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir los estados de
actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles.
8. Modelado Físico De Un Sistema OO
8.1 Componentes
Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar
aspectos físicos de un sistema.
Una característica básica de un componente es que: “debe definir una abstracción precisa con una interfaz
bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y
compatibles.”
8.1.1 Interfaces
La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma
icónica y de forma expandida
8.1.2 Tipos de componentes
Existen básicamente tres tipos de componentes:
? Componentes de despliegue.
? Componentes producto del trabajo.
? Componentes de ejecución.
8.1.3 Organización de componentes
Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases.
8.1.4 Estereotipos de componentes
UML define cinco estereotipos estándar que se aplican a los componentes:
executable Componente que se puede ejecutar en un nodo.
8.2 Despliegue
8.2.1 Nodos
Vamos a definir un nodo como un elemento físico, que existe en tiempo de ejecución y representa un recurso
computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos
sirven para modelar la topología del hardware sobre el que se ejecuta el sistema. Un nodo debe tener un
nombre asignado que lo distinga del resto de nodos.
8.2.2 Nodos y componentes
En muchos aspectos los nodos y los componentes tienen características parecidas.
PARECIDOS
Ambos tienen nombre
DIFERENCIAS
Los Nodos Los Componentes Son los elementos donde se ejecutan los componentes.
Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de un sistema orientado a
objetos:
• Diagramas de Componentes
• Diagramas de Despliegue
8.3 Diagramas de Componentes
Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes.
8.3.1 Usos más comunes
a) Modelado de Código Fuente.
b) Modelado de una versión ejecutable y bibliotecas.
c) Modelado de una base de datos física
8.4 Diagramas de Despliegue
8.4.1 Técnicas más comunes de modelado
a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es más que el desarrollo de un
sistema software. Hay que manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la
25
comunicación entre los ingenieros de hardware y los de software.
b) Modelado de un sistema cliente servidor La división entre cliente y servidor en un sistema es complicada
ya que implica tomar algunas decisiones sobre dónde colocar físicamente sus componentes software, qué
cantidad de software debe residir en el cliente, etc.
8.5 Arquitectura del Sistema
8.5.1 Arquitectura de tres niveles
La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de información que además de
tener una interfaz de usuario contemplan la persistencia de los datos.
Una descripción de los tres niveles sería la siguiente:
Nivel 1: Presentación – ventanas, informes, etc.
Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.
Nivel 3: Almacenamiento – mecanismo de almacenamiento.
8.5.2 Arquitectura de tres niveles orientadas a objetos
a) Descomposición del nivel de lógica de la aplicación En el diseño orientado a objetos, el nivel de lógica de
la aplicación se descompone en sub-niveles que son los siguientes:
Objetos del Dominio: son clases que representan objetos del dominio.
Servicios: se hace referencia a funciones de interacción con la base de datos, informes, comunicaciones,
seguridad, etc.
8.5.3 Arquitectura MULTI-nivel
La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si tenemos en cuenta el hecho de
que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez
más.
8.5.4 Paquetes
La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de Paquetes, pudiéndose
anidar los paquetes formando jerarquías de paquetes. De hecho un sistema que no tenga necesidad de ser
descompuesto en subsistemas se puede considerar como con un único paquete que lo abarca todo.
8.5.5 Identificación de Paquetes
• Conviene agrupar elementos que proporcionen un mismo servicio.
• Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesión, es decir
deben estar muy relacionados.
• Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben colaborar lo
menos posible.
9 Proceso de Desarrollo
Cuando se va a construir un sistema software es necesario conocer un lenguaje de programación, pero con
eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado
y la solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto, que incluya las actividades
principales.
9.1 Visión General
El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos
vamos a encontrar al intentar desarrollar cualquier sistema software de tamaño medio-alto. El proceso está
formado por una serie de actividades y subactividades, cuya realización se va repitiendo en el tiempo
aplicadas a distintos elementos.
Las tres fases al nivel más alto son las siguientes:
• Planificación y Especificación de Requisitos.
• Construcción: La construcción del sistema.
Las fases dentro de esta etapa son las siguientes:
- Diseño de Alto Nivel.
- Diseño de Bajo Nivel.
- Implementación.
- Pruebas.
• Instalación.
26
independiente del paradigma empleado posteriormente.
9.2 Requisitos
El formato del documento de Especificación de Requisitos no está definido en UML, pero se ha incluido este
punto para resaltar que la actividad de definición de requisitos es un paso clave en la creación de cualquier
producto software. Para entender y describir los requisitos la técnica de casos de uso constituye una valiosa
ayuda.
9.3 Casos de Uso
Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer
un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en
particular requisitos funcionales.
Un escenario es un camino concreto a través del caso de uso, una secuencia específica de acciones e
interacciones entre los actores y el sistema.
En un primer momento interesa abordar un caso de uso desde un nivel de abstracción alto, utilizando el
formato de alto nivel.
9.3.1 Casos de Uso de Alto Nivel
El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se está usando un cajero
automático:
- Caso de Uso: Realizar Reintegro
- Actores: Cliente
- Tipo: primario
- Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una
operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la
operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va.
27
casos de uso. Esto es, a cada ciclo de desarrollo se le va a asignar la implementación de uno o más casos de
uso, o versiones simplificadas de casos de uso.
Para tomar la decisión de qué casos de uso se van a tratar primero es necesario ordenarlos según prioridad.
Las características de un caso de uso específico que van a hacer que un caso de uso tenga una prioridad alta
son las siguientes:
a. Impacto significativo en el diseño de la arquitectura. Por ejemplo, si aporta muchas clases al modelo del
dominio o requiere persistencia en los datos.
b. Se obtiene una mejor comprensión del diseño con un nivel de esfuerzo relativamente bajo.
c. Incluye funciones complejas, críticas en el tiempo o de nivel elevado de riesgo.
d. Implica bien un trabajo de investigación significante, o bien el uso de una tecnología nueva o arriesgada.
e. Representa un proceso de gran importancia en la línea de negocio.
f. Supone directamente un aumento de beneficios o una disminución de costes.
28
10.2.4 Identificación de Atributos
Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de
información de los casos de uso que se estén desarrollando en ese momento.
Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser
modelados como conceptos y ser relacionados mediante asociaciones.
10.3 Glosario
En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para
eliminar toda posible ambigüedad. Se ordena alfabéticamente por término.
10.4 Diagramas de Secuencia del Sistema
Además de investigar sobre los conceptos del sistema y su estructura, también es preciso investigar en el
Diseño de Alto Nivel sobre el comportamiento del sistema, visto éste como una caja negra. Una parte de la
descripción del comportamiento del sistema se realiza mediante los Diagramas de Secuencia del Sistema.
En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores
generan eventos, solicitando al sistema operaciones.
Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina
escenario, y muestra una ejecución real del caso de uso, con las posibles bifurcaciones y alternativas
resueltas de forma particular.
Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de secuencia de
UML
10.5 Contratos de Operaciones
Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se describe
mediante contratos el comportamiento esperado del sistema en cada operación.
Un Contrato es un documento que describe qué es lo que se espera de una operación.
10.5.1 Post-condiciones
Las post-condiciones se basan en el Modelo Conceptual, en los cambios que sufren los elementos del mismo
una vez se ha realizado la operación.
Es mejor usar el tiempo pasado o el pretérito perfecto al redactar una post-condición, para enfatizar que se
trata de declaraciones sobre un cambio en el estado que ya ha pasado.
10.6 Diagramas de Estados
Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que define UML (ver
página 13).
Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos:
- Una clase software.
- Un concepto.
- Un caso de uso.
10.7 Fase de Construcción: Diseño de Bajo Nivel
En la fase de Diseño de Bajo Nivel se crea una solución a nivel lógico para satisfacer los requisitos,
basándose en el conocimiento reunido en la fase de Diseño de Alto Nivel. Los modelos más importantes en
esta fase son el Diagrama de Clases de Diseño y los Diagramas de Interacción, que se realizan en paralelo y
que definen los elementos que forman parte del sistema orientado a objetos que se va a construir.
10.7.1 Casos de Uso Reales
Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de entrada y de
salida y su implementación. Si el caso de uso implica una interfaz de usuario, el caso de uso real incluirá
bocetos de las ventanas y detalles de la interacción a bajo nivel con los widgets.
10.7.2 Diagramas de Interacción
Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo de clases
para cumplir las post-condiciones establecidas en un contrato
Hay dos clases de Diagramas de Interacción:
1. Diagramas de Colaboración.
2. Diagramas de Secuencia.
10.7.2.1 Creación de Diagramas de Interacción
Para crear los Diagramas de Colaboración o de Secuencia se pueden seguir los siguientes consejos:
• Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de desarrollo actual.
• Conocer:
- Conocer datos privados encapsulados.
- Conocer los objetos relacionados.
- Conocer las cosas que puede calcular o derivar.
29
• Hacer:
- Hacer algo él mismo.
- Iniciar una acción en otros objetos.
- Controlar y coordinar actividades en otros objetos.
10.8 Diagrama de Clases de Diseño
Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación.
Incluye la siguiente información:
• Clases, asociaciones y atributos.
• Interfaces, con sus operaciones y constantes.
• Métodos.
• Navegabilidad.
• Dependencias.
A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de entidades
software más que conceptos del mundo real.
10.8.1 Relaciones de Dependencia para Representar Visibilidad entre Clases
Cuando una clase conoce a otra por un medio que no es a través de un atributo (una asociación con la
navegabilidad adecuada), entonces es preciso indicar esta situación por medio de una dependencia.
Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de
dependencia:
- Parámetro.
- Local.
- Global.
10.8.2 Navegabilidad
La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible
“navegar” unidireccionalmente a través de la asociación, desde objetos de la clase origen a objetos de la
clase destino. La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la
clase origen.
10.8.3 Visibilidad de Atributos y Métodos
Los atributos y los métodos deben tener una visibilidad asignada, que puede ser:
+ Visibilidad pública.
# Visibilidad protegida.
- Visibilidad privada.
También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementación
que sean necesarios para completar el Diagrama de Clases.
10.9 Otros Aspectos en el Diseño del Sistema
En el diseño de un sistema es necesario también tomar decisiones a un nivel más alto sobre la
descomposición de un sistema en subsistemas y sobre la arquitectura del sistema. Estas decisiones no se
toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo
tradicional.
Fases de Implementación y Pruebas
Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el lenguaje de
programación elegido
El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede
probar con los futuros usuarios, e incluso poner en producción si se ha planificado una instalación gradual.
30
JOSE EDUARDO GARCIA
31
Un inventario representa la existencia de bienes muebles e inmuebles que tiene la empresa para
comerciar con ellos, comprándolos y vendiéndolos tal cual o procesándolos primero antes de
venderlos, en un período económico determinado. Deben aparecer en el grupo de Activo Circulante.
La base de toda empresa comercial es la compra y venta de bienes o servicios; de aquí la
importancia del manejo del inventario por parte de la misma.
El inventario constituye las partidas del activo corriente que están listas para la venta, es decir, toda
aquella mercancía que posee una empresa en el almacén valorada al costo de adquisición, para la
venta o actividades productivas.
Inventario de Mercancías:
Lo constituyen todos aquellos bienes que le pertenecen a la empresa bien sea comercial o mercantil,
los cuales los compran para luego venderlos sin ser modificados. En esta Cuenta se mostrarán todas
las mercancías disponibles para la Venta. Las que tengan otras características y estén sujetas a
condiciones particulares se deben mostrar en cuentas separadas, tales como las mercancías en
camino (las que han sido compradas y no recibidas aún), las mercancías dadas en consignación o las
mercancías pignoradas (aquellas que son propiedad de la empresa pero que han sido dadas a
terceros en garantía de valor que ya ha sido recibido en efectivo u otros bienes).
La contabilidad para los inventarios forma parte muy importante para los sistemas de contabilidad
de mercancías, porque la venta del inventario es el corazón del negocio.
Las empresas dedicadas a la compra y venta de mercancías, por ser esta su principal función y la
que dará origen a todas las restantes operaciones, necesitaran de una constante información
resumida y analizada sobre sus inventarios, lo cual obliga a la apertura de una serie de cuentas
principales y auxiliares relacionadas con esos controles.
Entre estas cuentas podemos nombrara las siguientes:
Inventario Inicial:
Representa el valor de las existencias de mercancías en la fecha que comenzó el periodo contable
Compras:
En la cuenta compras se incluye las mercancías compradas durante el periodo contable con el objeto
de volver a venderlas con fines de lucro y que forman parte del objeto para el cual fue creada la
empresa.
Devoluciones en compra:
Devoluciones en compra se refiere a la cuenta que es creada con el fin de reflejar toda aquella
mercancía comprada que la empresa devuelve por cualquier circunstancia.
Gastos de compras:
Los gastos ocasionados por las compras de mercancías deben dirige a la cuenta titulada: Gastos de
Compras. Esta cuenta tiene un saldo deudor y no entra en el Balance General.
Ventas:
Esta cuenta controlará todas las ventas de mercancías realizadas por la Empresa y que fueron
compradas con este fin.
Devoluciones en venta:
32
También tenemos Devoluciones en Venta, la cual está creada para reflejar las devoluciones
realizadas por los clientes a la empresa.
Mercancía de transito:
En algunas oportunidades, especialmente si la empresa realiza compras en el exterior, nos
encontramos que se han efectuado ciertos desembolsos o adquirido compromisos de pago
(documentos o giros) por mercancías que la empresa compró pero que, por razones de distancia o
cualquier otra circunstancia, aun no han sido recibidas en el almacén. Para contabilizar este tipo de
operaciones se debe utilizar la cuenta: Mercancías en Tránsito.
Inventario (Final)
El Inventario Actual (Final) se realiza al finalizar el periodo contable y corresponde al inventario
físico de la mercancía de la empresa y su correspondiente valoración.
Clases de Inventarios:
Son todos aquellos bienes adquiridos por las empresas manufactureras o industriales, los cuales son
transformados para ser vendidos como productos elaborados.
Lo integran todos aquellos bienes adquiridos por las empresas manufactureras o industriales, los
cuales se encuentran en proceso de manufactura. Su cuantificación se hace por la cantidad de
materiales, mano de obra y gastos de fabricación, aplicables a la fecha de cierre.
Lo conforman todos los materiales con los que se elaboran los productos, pero que todavía no han
recibido procesamiento.
Son los materiales con los que se elaboran los productos, pero que no pueden ser cuantificados de
una manera exacta (Pintura, lija, clavos, lubricantes, etc.).
Sistemas de inventario:
El Sistema de Inventario Perpetuo:
En el sistema de Inventario Perpetuo, el negocio mantiene un registro continuo para cada artículo
del inventario.
Los registros perpetuos son útiles para preparar los estados financieros mensuales, trimestral o
provisionalmente. EL negocio puede determinar el costo del inventario final y el costo de las
mercancías vendidas directamente de las cuentas sin tener que contabilizar el inventario. El sistema
33
perpetuo ofrece un alto grado de control, porque los registros de inventario están siempre
actualizados.
El saldo de la cuenta inventario bajo el sistema perpetuo deberá resultar en el costo del inventario
disponible en cualquier momento.
Los registros de inventario perpetuo proporcionan información para las siguientes decisiones:
•La mayoría de las tiendas de mobiliario, guarda la mercancía en sus almacenes, por lo tanto
los empleados no pueden examinar visualmente la mercancía disponible y dar respuesta en ese
mismo instante. El sistema perpetuo le indicará oportunamente la disponibilidad de dicha
mercancía.
•Los registros perpetuos alertan al negocio para reorganizar el inventario cuando éste se
muestra bajo.
•Si las compañías preparan los estados financieros mensualmente, los registros de inventario
perpetuo muestran el inventario final existente, no es necesario un conteo físico en este
momento; sin embargo, es necesario un conteo físico una vez al año para verificar la exactitud
de los registros.
Asientos bajo el Sistema Perpetuo
En el sistema de inventario perpetuo, el negocio registra las compras de inventario cargando
a la cuenta inventario, cuando el negocio realiza una venta, se necesitan dos asientos. La
compañía registra la venta de la manera usual, carga a efectivo o a cuentas por cobrar y
abona a ingresos por ventas el precio de las mercancías vendidas.
34
El Sistema de Inventario Periódico:
En el sistema de inventario periódico el negocio no mantiene un registro continuo del inventario
disponible, más bien, al fin del periodo, el negocio hace un conteo físico del inventario disponible y
aplica los costos unitarios para determinar el costo del inventario final.
El sistema periódico es conocido también como sistema físico, porque se apoya en el conteo físico
real del inventario. El sistema periódico es generalmente utilizado para contabilizar los artículos del
inventario que tienen un costo unitario bajo. Los artículos de bajo costo pueden no ser lo
suficientemente valiosos para garantizar el costo de llevar un registro al día del inventario
disponible.
Este trabajo fue realizado a base de conocimiento en el tema sobre el inventario el cual
fue estudiado a fondo con sus distintos tipos, clases y sistemas de inventario.
También concluimos con una de las etapas del la metodología de orientación a objetos,
gracias al bosquejo del lenguaje UML, que nos permitió visualizar, especificar y
documentar cada una de las partes que comprende el análisis del sistema para dicha
empresa
La síntesis realizada por cada uno de los integrantes, pudo afianzar el conocimiento en
cada uno de las áreas del análisis. También cada una de las áreas, así como la utilización
del modelo UML.