Está en la página 1de 68

Universidad Nacional de Ingeniera

Recinto Universitario Simn Bolvar


Facultad de Electrotecnia y Computacin

Nombre:
Arlen Janet Lpez 2007-22565

Docente:
Ing. Geovanny Senz

Managua, Abril 2011

UNIVERSIDAD NACIONAL DE INGENIERIA

ndice

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

INTRODUCCIN .................................................................................................................................... 3 DESCRIPCIN DE LA SITUACIN ........................................................................................................... 4 OBJETIVOS ........................................................................................................................................... 6 ALCANCE DEL PROYECTO. ..................................................................................................................... 8 BENEFICIOS DE AUTOMATIZAR ............................................................................................................ 9 REQUERIMIENTOS FUNCIONALES....................................................................................................... 11 RESTRICCIONES DEL SISTEMA ............................................................................................................. 12 DIAGRAMAS DE FLUJO DE DATOS ...................................................................................................... 14 FACTIBILIDAD TCNICA....................................................................................................................... 16 FACTIBILIDAD ECONMICA ........................................................................................................... 21 FACTIBILIDAD OPERATIVA ............................................................................................................. 24 FACTIBILIDAD LEGAL ..................................................................................................................... 26 ANLISIS DE ALTERNATIVAS .......................................................................................................... 27

ANLISIS COSTO BENEFICIO ............................................................................................................... 27 ANLISIS TCNICO DE LAS ALTERNATIVAS .................................................................................... 28 ALTERNATIVA RECOMENDADA .......................................................................................................... 28 14. ANLISIS DE DATOS ....................................................................................................................... 29 14.1.1 Diagrama de casos de uso ...................................................................................................... 30

CASO DE USO ADMINISTRATIVO....................................................................................................... 31 CASO DE USO : CONTRATISTA ........................................................................................................... 31 CASO DE USO: CLIENTE ........................................................................................................................ 32 CASO DE USO : PROVEEDOR .............................................................................................................. 33 CASO DE USO : BODEGA ..................................................................................................................... 33 14.1.2 14.1.3 15. Diagrama de clases: ............................................................................................................... 35 Tarjetas CRC ........................................................................................................................... 36

DISEO DE DATOS ......................................................................................................................... 37 15.1.1 Diagrama de Secuencia .......................................................................................................... 37

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

COTIZAR: ................................................................................................................................................. 37 COMPRAR: .............................................................................................................................................. 37 CONTRATISTA: ....................................................................................................................................... 38 ORDEN DE COMPRA: ............................................................................................................................ 38 SOLICITUD: .............................................................................................................................................. 39 15.1.2 15.1.3 16. 17. Diagrama Colaboracin: ........................................................................................................ 39 Diagramas de estados ............................................................................................................ 42

CONCLUSIONES ............................................................................................................................. 45 INTRODUCCIN A UML ................................................................................................................. 46 17.1.1 Diagramas. Vistazo general ................................................................................................... 48 17.1.2 Diagrama de casos de uso ...................................................................................................... 50 17.1.3 Diagrama de clases ................................................................................................................ 55 La Clase ..................................................................................................................................................... 55 Relaciones entre clases ............................................................................................................................. 56 Dependencias ........................................................................................................................................... 56 Generalizacin .......................................................................................................................................... 58 Asociacin ................................................................................................................................................. 59 17.1.4 Tarjetas CRC ........................................................................................................................... 59 17.1.5 Diagramas de objetos ............................................................................................................ 59 17.1.6 Diagrama de componentes .................................................................................................... 60 Ejecutables................................................................................................................................................ 61 17.1.7 Diagramas secuencia ............................................................................................................. 62 17.1.8 Diagramas Estados ................................................................................................................. 64

18.

ANLISIS DE RIESGOS .................................................................................................................... 67

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

1. Introduccin
Construmel, es una pequea constructora que esta

ejecutando su primer proyecto, este se llama Urbanizacin Bruselas ubicada en la comarca Las Jaguitas, de las cuatro esquinas 90 mts al noreste en el departamento de Managua. El sistema administrativo que se pretende implementar en la empresa Construmel llevar el control de: solicitudes,

entradas y salidas de los diferentes tipos de materiales utilizados por los diferentes contratistas que se encargan de la construccin de las casas. El sistema brindar gran apoyo a la parte administrativa, porque se almacenar los datos referente a los

proveedores, materiales, as como el control de pagos que se efectan, por lo que el sistema llevar el control de gran

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

cantidad de informacin de manera ordenada y especifica, evitando as perdidas o mal uso de materiales. Todas estas actividades estarn siendo manejadas y controladas por el sistema priorizando su realizacin en tiempo y forma.

2. Descripcin de la situacin
Departamento de ventas: El departamento de ventas est

compuesto por una vendedora que atiende a los clientes cuando estos llegan a cotizar las casas, les muestra los diferentes estilos que tienen y la forma en que estos pueden ser adaptados a la

necesidad del cliente, posteriormente si el cliente esta satisfecho y

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

decide hacer la compra establece la comunicacin entre el banco con el cliente para que este pueda acceder a un crdito hipotecario. Departamento de administracin: Compuesto por un empleado

administrativo el cual es el vinculo entre la empresa y los


Ingenieros contratistas, este recibe las solicitudes de materiales evala dichas solicitudes y si ameritan la compra, emite una orden de compra a los proveedores, y luego entrega estos mismos materiales a Bodega, Esta se encarga de recibir y llevar un control de las compras de los materiales, y entregarlas a los contratistas

para su uso. Contador: Se encarga de llevar la contabilidad de la empresa. Procesos actuales en la agencia: La empresa actualmente recibe a sus clientes en la casa modelo . es en esta casa donde tienen sus oficinas, solo existen 3 empleados en planilla: la vendedora, la empleada administrativa y un contador, los dems empleados son subcontratados a terceras empresas las cuales se encargan a su vez de la construccin de las casas, estas empresas se dividen en: Construccin Fontanera Carpintera (Puertas y ventanas) Acabados (Pinturas)

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Estos contratistas solo ponen la mano de obra los materiales los suministra la empresa Construmel, el contratista solicita el material al empleado administrativo para su compra, el empleado valora la solicitud si esta es aprobada emite una orden de compra y pide a los proveedores el material que luego es almacenado en bodega. Todo este proceso de solicitudes y control de entradas y salidas de material es elaborado a mano, o en archivos de paquetes de ofimtica, por lo que no se lleva un control estricto y deja la pauta a que puedan haber perdidas o no se cuantifica exactamente el valor de una casa cuando esta recibe modificaciones. En los egresos se encuentran los pagos correspondientes en planilla (contador, administrativo, vendedor), pagos de servicios bsicos (agua, luz, telfono), gastos de oficina, impuestos.

3. Objetivos

General
Llevar el control administrativo de la Empresa constructora Construmel

Especficos
6 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Llevar un Control de inventario de los materiales

de construccin.
Calcular los costos de la vivienda segn las

adaptaciones establecidos.

hechas

los

modelos

pre-

Generar nomina de pago de empleados fijos y

contratistas.
Reducir las inconsistencias y redundancias de

datos.

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

4. Alcance del proyecto.


El alcance el presente proyecto estar enfocado a: Llevar un control sistematizado y ordenado de los materiales que se utilizan para construir una vivienda, Mostrar al cliente de manera grfica los diferentes tipos de

modelos de vivienda y cual seria el costo si a ese modelo bsico se le hicieran modificaciones, Facilitar al trabajador a realizar con mayor agilidad los distintos tipos de transacciones que se realizan por medio del sistema, El sistema estar compuesto por dos mdulos: El modulo de control de inventario. El modulo de presentacin de modelos. El de inventario estar compuesto por varios procesos los cuales son:

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

1. El primer proceso se encargara de las entradas y salidas de los materiales, as como el estado de existencia y fecha de entrada a bodega , incluyendo el informacin detallada de

proveedores. El proceso tendr los catlogos de los productos, de Proveedores. 2. El segundo proceso ser el que realice los reportes

mensuales de lo requerido por la Empresa. En el modulo de presentacin de modelos, se crear una interfaz grafica que muestre al cliente los modelos disponibles, luego si el cliente quiere hacer una reforma a este modelo, mostrara el costo adicional que incluye dicha reforma e imprimir dicha cotizacin para el cliente.

5. Beneficios de Automatizar
Beneficios Cuantificables

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Disminucin prdidas de materiales, El sistema lleva el control de las entradas y salidas del material de forma automtica y clara. Reduccin del tiempo de procesamiento, el sistema verificar si amerita o no la compra de material. Beneficios No Cuantificables Mejor atencin al cliente, el sistema le podr mostrar la

informacin de una manera exacta y eficaz. Rapidez en la comunicacin inter-empresarial el sistema

llevara las diferentes actividades que se realizara en la empresa. Mejor imagen de la empresa, mayor competitividad comercial. Mayor satisfaccin del personal por la reduccin del tiempo en sus horas laborales labores diarias. Beneficiara en Incremento de la certeza en la toma de

decisiones estratgicas, por parte del personal administrativo en la realizacin de pedidos en la fecha establecida. Reduccin de controles manuales por parte de administracin ya que estos controles se llevaran automticamente mediante reportes con la frecuencia establecida en los requerimientos.
10 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

6. Requerimientos Funcionales
1. Generar dos nominas de pagos: Quincenal correspondiente al departamento de ventas, administrativo y contador, Mensual para el pago a los contratistas La nmina se genera en la frecuencia establecida. 2. Generar reporte peridico de existencia en bodega para poder

emitir un pedido de producto para reabastecer, el reporte contendr informacin de cada producto.: tipo de material, el proveedor que lo abastece, cantidad de material.

3. Registrar

orden de pedidos realizados a proveedor para

reabastecer bodega donde se detalla proveedor, categora de

11

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

producto , costos unitario categora , cantidad de subtotal costo * categora , producto , total a pagar, tipo de compra, fecha de pago.

4. Generar el clculo de la vivienda cuando el cliente realiza cambios en el modelo pre-establecido.

7. Restricciones del Sistema

12

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

El sistema no realizara supervisiones en la calidad de los materiales.

El sistema no realizara transacciones bancarias mediante la web, ya que este no es un sistema que se desarrollara bajo la web.

El sistema no llevar control de los clientes, ya que esto solo lo realiza el banco que brinda el crdito hipotecario.

13

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

8. Diagramas de Flujo de Datos

14

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Diagrama de Contexto
15 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

9. Factibilidad Tcnica
Propuesta SACo El desarrollo del proyecto es factible si se dispone de los recursos adecuados. Para desarrollar esta aplicacin se propone la

implementacin de un sistema

de arquitectura de una sola capa. de 1

Esta arquitectura consiste en la utilizacin suficiente

computadora en la cual la unidad ejecutable de la aplicacin estar instalada, sin necesidad de un servidor web , ya que se ejecutara como una aplicacin de escritorio y no con exploradores que

mediante una conexin a Internet se conectan a un servidor en el cual reside la aplicacin. El siguiente diagrama representa la arquitectura utilizada: Arquitectura cliente servidor en tres capas lgicas: Arquitectura de tres capas lgicas, 2 niveles fsicos en la que la aplicacin est en una computadora como cliente y servidor al mismo tiempo, pero las capas de procesamiento son individuales. Teniendo en cuenta la disponibilidad de los medios y recursos con los que actualmente se cuentan en la empresa, esta aplicacin est pensada para implementarse dicha arquitectura ya que no

representa ningn desafo tcnico, debido a que su instalacin es

16

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

sencilla e intuitiva, solamente se necesita una sola computadora que es con la que actualmente se trabaja en el negocio. EQUIPO DE DESARROLLO Tecnologa de desarrollo (Aplicacin de escritorio) El desarrollo de aplicaciones web es el ms utilizado en la actualidad, especialmente en ambientes empresariales. Pero las

aplicaciones de escritorio en la intranet de una empresa tambin es una alternativa que a pesar de ser menos reciente, se tiene un nivel de rapidez en comparacin a la tecnologa de aplicaciones web. Desde que conocemos la informtica han existido programas de

gestin para Windows por este motivo se utilizan muchas tecnologas pero las principales son: visual.net(C#, VBasic, VStudio) , c++ y en ocasiones java. La implementacin de la aplicacin ser un desarrollo a medida bajo .net en la plataforma de visual studio

2005.net en conjunto con el gestor de base de datos SQL Server 2005. Las razones que hace ser elegible este tipo de aplicacin bajo .net son:

17

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Navegacin e interfaz de usuario ms rpida que en una aplicacin web. Normalmente no es necesaria una conexin a internet ya que funciona localmente o en la intranet de la empresa. Es mejor opcin cuando es necesario realizar numerosos

clculos o procesos de CPU muy intensivos Las razones por las que se utilizara .net: Permite en combinacin con el gestor de base de datos la creacin de una aplicacin de escritorio robusta y muchas herramientas que dan un aporte al programador por su facilidad de programar en estos entornos. Adems son reconocidas y con el tiempo se han ido perfeccionando por la gran utilidad empresarial que tiene en el mercado. En conclusin podemos decir que, como este tipo de desarrollo es el ms comn desde hace unos aos, no presenta dificultades tcnicas su utilizacin. Alternativa 1

Estrategias de Hardware
Para la eleccin del Hardware correspondiente, se realizaron estudios de requerimientos mnimos y recomendados del sistema.

18

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Tomando como referencia los requerimientos mnimos del sistema y la realizacin de la evaluacin de hardware existente en la empresa, para determinar la posibilidad de utilizar los mismos para el desarrollo e instalacin del Sistema SACo. obtenemos los

siguientes datos de hardware:

Hardware.
Procesador: Intel Core 2 duo 3.0 GHZ, Memoria RAM: 1GB Disco Duro: 500 GB, Monitor: 15 1024x768px.

Estrategia del Software


En cuanto a software, ser necesario trabajar bajo la plataforma Windows de Microsoft, para el desarrollo e instalacin del sistema se realizo un estudio con el cual determinamos los siguientes recursos de Software: Sistema Operativo Windows XP (versin Home o Profesional) con Service Pack 3 Microsoft SQL Server 2005.

19

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Microsoft Visual Studio 2005. Package Microsoft FrameWork.Net 2.0

Estrategia de RRHH
2 programadores : Experiencia en desarrollo de software bajo plataforma .Net , recomendado Visual Basic.Net , excelente dominio del gestor de base de datos SQL server 2005 , Un Analista: Datos, Buen anlisis y implementacin de Bases de de trabajo en equipo,

excelente

metodologa

experiencia mnimo 1 aos en proyectos de aplicacin administrativos. 1 diseador: Mnimo 3 aos de experiencia en diseo de software de aplicacin Alternativa 2 Los recursos y la capacidad tcnica de esta propuesta sern analizados, para establecer si es factible tcnicamente optar por esta solucin, ac es importante determinar si se cuenta con los recursos suficientes (los recursos necesarios).

Hardware
2 PCs, Procesador AMD Athlon 2Ghz, 2GB de RAM, Disco Duro 250, Monitor 15 1024x768px.
INGENIERIA DE SOFTWARE I

20

UNIVERSIDAD NACIONAL DE INGENIERIA

Hub de 6 puertos 10/100 Mbps.

Estrategia del Software


Sistema Operativo Windows XP (versin Home) con Service Pack 3 Sql SERVER 2008. Visual Basic 2008.

10. Factibilidad Econmica


Alternativa 1

Costos de Inversin
HARDWARE Cantidad Descripcin
1 Computadora de escritorio especificaciones en Alternativa 1 (existe en la empresa)

Precio Unitario
$0

Precio Total
$0

Subtotal SOFTWARE Cantidad Descripcin


1 Visual Studio .NET (se usar la versin xpress) Sql Server 2004 se usar la versin xpress)

Precio Unitario
$0

Precio Total

$0

21

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Subtotal Subtotal TOTAL

Costos de Desarrollo
Cantidad Rol
2 1 1 Programador Analista Diseador

Salario Mensual Meses Total


$400 $ 500 $300 2 3 2 $1600 $1500 $600

TOTAL

$3700

Costo Total
Cantidad
Costo de Inversin Costo de Desarrollo Costos Complementarios

Totales
$0 $0 $3700

Subtotal GRANT TOTAL

$3700 $3700

Alternativa 2

Costos de Inversin
HARDWARE Cantidad Descripcin
2 Computadora

Precio Unitario
$345

Precio Total
$690

22

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Hub

$6.95

$6.95

Subtotal SOFTWARE Cantidad Descripcin Precio Unitario

$696.95

Precio Total

Sistema

Operativo

Windows

XP

(versin Home) con Service Pack 3 Sql SERVER 2008. Visual Basic 2008
Subtotal

Costos de Desarrollo
Cantidad Rol
1 Programador 1 1 Analista Diseador

Salario Mensual Meses Total


$400 $500 $300 3 $1200 3 $1500 2 $600

TOTAL

$3300

Costo Total
Cantidad
Costo de Inversin Costo de Desarrollo

Totales
$696.95 $3300

Subtotal

$3996.95

23

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Cantidad GRAN TOTAL

Totales $3996.95

11. Factibilidad Operativa


El impacto que causar la implementacin del sistema en la institucin ser positivo ya que no se prevn cambios

organizacionales, sino, que ayudara al usuario a realizar sus tareas con mayor eficiencia, no se debe prescindir de los servicios de ninguno de los trabajadores con que cuenta la empresa

24

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

actualmente, el recurso humano sigue siendo el ms preciado dentro de la misma, sern ellos (el administrador) los que permitirn el buen funcionamiento de software propuesto para determinar en el futuro que tan beneficioso fue para SACo la contratacin de este proyecto informtico. El equipo de desarrollo garantizara la capacitacin necesaria al personal tcnico de la empresa ya que este ser el encargado de realizar el cargado inicial de datos al sistema. Desde el punto de vista operativo, el impacto del nuevo sistema aplicado a la empresa ser positivo y sin grandes problemas debido a : En primera instancia, la idea surge de necesidades (apoyo en el manejo y procesamiento de la informacin que respecta a las actividades de la empresa) detectada por la parte

administracin de la empresa. Por lo cual, ste sistema se enfoca a resolver un problema concreto y que fija un punto de partida a la resolucin de los problemas por ellos planteado. Por otro lado, la implementacin del mismo no representa un cambio radical en los circuitos principales, que se llevan a cabo durante los procesos que realiza la empresa. El sistema presentar una interfaz requerir en concepto de muy intuitiva que solo previos, estar

conocimientos

25

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

familiarizado con una PC. Conceptos con los que, hoy en da, la gente est cada vez ms en contacto tanto en el hogar como durante sus tareas laborales. De todas formas, evaluando el personal que se ver afectado por el software notamos lo siguiente: En el caso del departamento de ventas estos la nica interaccin con el sistema ser la interfaz grafica que muestra los modelos de las casas al cliente con sus respectivas modificaciones no tendrn acceso al manejo de la informacin que se mueve en la empresa. Desde el punto de vista de personal administrativo y contabilidad, estamos hablando de personal capacitado para llevar la

administracin y finanzas de la empresa, quienes inclusive durante sus roles o actividades necesitaron valerse de una PC para buscar informacin de las ventas realizadas a los clientes o generar

informes en algn procesador de texto.

12. Factibilidad Legal


En el desarrollo e implementacin del Sistema Administrativo

SACo se har uso de varias herramientas de sistema (Gestores de base de datos, lenguajes de programacin) , en las cuales se necesitan que cuenten con las debidas normas legales para poder hacer uso de ellas.
26 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

En cuanto a la funcionalidad del Sistema este adoptara las mismas normas que se trabaja actualmente en la empresa y estar sujeto a cualquier cambio de polticas., cabe mencionar que estas normas o reglamento en estos momentos se encuentra en reforma y en

espera de su aprobacin, debido a esto existe la posibilidad de violentar algunas normas una vez que estas sean aprobadas, es por ello que el termino legal queda abierto para su posible reforma.

13.Anlisis de Alternativas
Anlisis Costo Beneficio
Costos Totales
Representan los costos que la empresa interesada debe de incurrir para la implantacin del sistema. Para informacin detallada de las

propuestas se hace referencia en la seccin de factibilidad tcnica.

Clasificacin de Costos Alternativa 1


Costo de Inversin Costo de Desarrollo Costos Complementarios $0 $3300 --

Alternativa 2
$0 $3996.95--

TOTAL

$3300

$ 3396.95

27

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Anlisis Tcnico de las Alternativas


Evaluacin de alternativas
La mejor alternativa en base a la evaluacin hecha, es la propuesta nmero uno, ya que cumple adecuadamente con los factores que se han evaluado. El personal propuesto por la alternativa 1 cuenta con la experiencia necesaria en desarrollo de sistemas de este tipo y muchos aos de experiencia en el desarrollo de software. La plataforma tecnolgica propuesta por la alternativa nmero 1 es ms reconocida en el mercado, adems que hay mayor cantidad de profesionales con experiencia en desarrollar con esta solucin. Los recursos tcnicos con que cuenta el grupo que presento la alternativa 1, incluyendo su material humano posee una elevada calidad tcnica, cuenta con experiencia suficiente y a desarrollado varios proyectos similares a este. Gracias a que la alternativa 1 tendr una duracin menor a 12 meses.

Alternativa recomendada
Podemos evaluar dos enfoques alternativos en la etapa de desarrollo:
28 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Adaptar una aplicacin de escritorio: Tomar dicha aplicacin, ajustarla de acuerdo a las exigencias del Cliente Crear un nuevo Software de manera especializada: La

construccin de un software a la medida es una de las propuestas aplicables de este proyecto, ya que podemos desarrollar un sistema partiendo de la raz del problema y dividiendo el problema en sub-problemas para un trato personalizado.

14. Anlisis de datos

29

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

14.1.1 Diagrama de casos de uso

30

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Caso de uso administrativo

Caso de uso : Contratista

31

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Caso de uso: Cliente

32

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Caso de uso : Proveedor

Caso de uso : Bodega

33

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

34

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

14.1.2 Diagrama de clases:

35

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

14.1.3 Tarjetas CRC

36

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

15. Diseo de datos


15.1.1 Diagrama de Secuencia

Cotizar:

Comprar:

37

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Contratista:

Orden de compra:

38

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Solicitud:

15.1.2 Diagrama Colaboracin:

39

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

40

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

41

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

15.1.3 Diagramas de estados

42

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

43

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

44

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

16. Conclusiones
Luego de analizar los requerimientos de la empresa y las posibles alterativas tanto tecnolgicas como de desarrollo podemos concluir: El sistema SACo desarrollado bajo plataforma visual studio 2005 .net y gestor de bases de datos SQL Server 2005 cumple con los requerimientos incluidos en el estudio de factibilidad.

Las necesidades de la empresa la cual recibir de forma gratuita ser parte benfica de este software.

45

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

17. Introduccin a UML


UML es una especificacin de notacin orientada a objetos. Divide cada proyecto en un nmero de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto. Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista esttica, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visin dinmica del sistema. Es decir, gracias al diseo de la parte dinmica del sistema podemos darnos cuenta en la fase de diseo de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, as como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representacin es

46

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

limitada, y que ayuda a disear un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagacin de mensajes ni de sincronizacin o recuperacin ante estados de error. En resumen, un

sistema debe estar bien diseado, pero tambin tambin solucionar problema debe intenta el de funcionar bien. UML

propiedad de cdigo que se da con los desarrolladores, al implementar un lenguaje de modelado comn para todos los desarrollos se crea una documentacin tambin comn, que cualquier desarrollador con conocimientos de UML ser capaz de entender, independientemente del lenguaje utilizado para el desarrollo. UML es ahora un estndar, no existe otra especificacin de diseo orientado a objetos, ya que es el resultado de las tres opciones existentes en el mercado. Su utilizacin es independiente del lenguaje de programacin y de las caractersticas de los proyectos, ya que UML ha sido diseado para modelar cualquier tipo de

47

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

proyectos, tanto informticos como de arquitectura, o de cualquier otro ramo.


17.1.1 Diagramas. Vistazo general

La explicacin se basar en los diagramas, en lugar de en vistas o anotacin, ya que son estos la esencia de UML. Se Dispone de dos tipos diferentes de diagramas los que dan una vista esttica del sistema y los que dan una visin dinmica. Los diagramas estticos son: Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los ms comunes y dan una vista esttica del proyecto. Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visin de casos reales. Diagrama de componentes: Muestran la organizacin de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones. Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen

48

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema. Lo diagramas dinmicos son: Diagrama de secuencia, Diagrama de colaboracin: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envan entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de informacin, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interaccin. Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son tiles en sistemas que reaccionen a eventos. Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos. Como podemos ver el nmero de diagramas es muy alto, en la mayora de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dar una breve explicacin de todos, amplindose para los ms necesarios.

49

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

17.1.2 Diagrama de casos de uso

Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como responde esa parte del sistema. El diagrama de uso es muy til para definir como debera ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como estn implementadas las partes que define. Por ello es un buen sistema de documentar partes del cdigo que deban ser reutilizables por otros desarrolladores. El diagrama tambin puede ser utilizado para que los expertos de dominio se comuniquen con los informticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto. Para crear un diagrama de casos de uso damos clic en la pantalla principal de UMl en Diagrama de casos de uso a continuacin le ponemos un nombre e iniciamos. En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:

50

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Actores: se representan por un mueco

Para agregar un actor solo damos clic en la figura y la arrastramos a la ventana de caso de uso

51

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Casos de uso: representado por una elipse, cada caso de uso contiene un nombre.

Para agregar un caso de uso damos clic ya sea en el actor y arrastramos hacia afuera o en la barra lateral caso de uso y damos clic sobre la ventana

Para relacionar los casos de uso de clic sostenido en Asociacin desde un actor hasta la asociacin que deseemos hacer

52

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Sus relaciones son: Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso. Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A. Generalization: Es la tpica relacin de herencia. .
53 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Communicates: Comunica un actor con un caso de uso, o con otro actor. Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.

En este grafico encontramos 10 casos de usos Cotizar


54 INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Cancela (Cuentas por pagar, planilla, servicios) Compra materiales (Al crdito, al contado) Abastecen material Almacena material Aprueba solicitud Despacha material Genera reporte de entrada Utiliza material Genera reporte de material usado.

17.1.3 Diagrama de clases

Forma parte de la vista esttica del sistema. En el diagrama de clases como ya hemos comentado ser donde definiremos las caractersticas de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalizacin. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseo orientado a objetos, definiendo las clases e implementando las ya tpicas relaciones de herencia y agregacin. En el diagrama de clases debemos definir a estas y a sus relaciones.
La Clase

Una clase esta representada por un rectngulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los mtodos.

55

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Cada clase debe tener un nombre nico, que las diferencie de las otras. Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los
Nombre

atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto. Un mtodo u operacin es la implementacin de

Atributos Mtodos

un servicio de la clase, que muestra un comportamiento comn a todos los objetos. En resumen es una funcin que le indica a las instancias de la clase que hagan algo. Para separar las grandes listas de atributos y de mtodos se pueden utilizar estereotipos.

Relaciones entre clases

Existen

tres

relaciones

diferentes entre

clases,

Dependencias,

Generalizacin y Asociacin. En las relaciones se habla de una clase


destino y de una clase origen. La origen es desde la que se realiza la accin de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha. Las relaciones se pueden modificar con estereotipos o con restricciones.
Dependencias

Es una relacin de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va

56

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningn estereotipo (palabreja que aparece al lado de la lnea que representa la dependencia) UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos. Estereotipos de relacin Clase-objeto. Bind: La clase utilizada es una plantilla, y necesita de parmetros para ser utilizada, con Bind se indica que la clase se instancia con los parmetros pasndole datos reales para sus parmetros. Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento. Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podr ver las interioridades de la clase destino. InstanceOF: Indica que el objeto origen es una instancia del destino. Instantiate: indica que el origen crea instancias del destino. Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.

57

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
Generalizacin

Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia mltiple. Aunque la representacin comn es suficiente en el 99.73% de los casos UML nos permite modificar la relacin de Generalizacin con un estereotipo y dos restricciones.

Estereotipo de generalizacin. Implementation: El hijo hereda la implementacin del padre, sin publicar ni soportar sus interfaces. Restricciones de generalizacin. Complete: La generalizacin ya no permite mas hijos. Incomplete: Podemos incorporar mas hijos a la generalizacin. Disjoint: solo puede tener un tipo en tiempo de ejecucin, una instancia del padre solo podr ser de un tipo de hijo. Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.

58

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Asociacin

Especifica que los objetos de una clase estn relacionados con los elementos de otra clase. Se representa mediante una lnea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregacin.

17.1.4 Tarjetas CRC

Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede usar para guiar el sistema a travs de anlisis guiados por la responsabilidad. Las clases se examinan, se filtran y se refinan en base a sus

responsabilidades con respecto al sistema, y las clases con las que necesitan colaborar para completar sus responsabilidades.

17.1.5 Diagramas de objetos

Forma parte de la vista esttica del sistema. En este diagrama se modelan las instancias de las clases del diagrama de clases. Muestra a los objetos y sus relaciones, pero en un momento concreto del sistema. Estos diagramas contienen objetos y enlaces. En los

59

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

diagramas de objetos tambin se pueden incorporar clases, para mostrar la clase de la que es un objeto representado.
17.1.6 Diagrama de componentes

Se utilizan para modelar la vista esttica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En el situaremos libreras, tablas archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema. Aqu tenemos un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el sistema no funcionara. En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representacin anterior es incorrecta, pero no es as solo corresponde a un nivel diferente de detalle.

60

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, los standard que define UML son: Executable Library Table File Document Aunque por suerte no estamos limitados a estas especificaciones. Que pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existe ya unos definidos WAE (Web Applications Extensin). Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas. Ejecutables y bibliotecas Tablas API Cdigo fuente Hojas HTML
Ejecutables

Nos facilita la distribucin de ejecutables a los clientes. Documenta sus necesidades y dependencias. Si disponemos de un ejecutable

61

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

que solo se necesita a el mismo para funcionar no necesitaremos el diagrama de componentes. Los pasos a seguir para modelar, a priori no a posteriori, son: Identificar los componentes, las particiones del sistema, cuales son factibles de ser reutilizadas. Agruparlos por nodos y realizar un diagrama por cada nodo que se quiera modelar. Identificar Considerar cada las componente relaciones con su estereotipo correspondiente. entre componentes. En este grafico se muestra un ejecutable que utiliza dos libreras, estas dos disponen de su interface con el que ofrecen acceso a sus servicios. Se puede ver que estas libreras son componentes que pueden ser reutilizados en otras partes del sistema.
17.1.7 Diagramas secuencia

libreras el

62

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

El diagrama de secuencia forma parte del modelado dinmico del sistema. Se modelan las llamadas entre clases desde un punto concreto del sistema. Es til para observar la vida de los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado esttico, que imposibiliten el flujo de informacin o de

El diagrama se forma con los objetos que forman parte de la secuencia

De estos objetos sale una lnea que indica su vida en el sistema.

llamadas entre los componentes del sistema. En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida.,

63

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

En esta pantalla tenemos un actor, situado a la izquierda que es el que inicia la accin Cotizacin, a un objeto Casa, si la cotizacin es exitosa entonces realiza la segunda accin Paga en cuotas
17.1.8 Diagramas Estados

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. En l se indican qu eventos hacen que se pase de un estado a otro y cules son las respuestas y acciones que genera.

64

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

En cuanto a la representacin, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transicin se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En
Inicio

el

primer

compartimento

aparece el nombre del estado. El segundo opcional, compartimento y en l es

pueden

aparecer acciones de entrada, de salida y acciones internas. Una accin de entrada aparece en la forma donde

entrada/accin_asociada

accin_asociada es el nombre de la accin que se realiza al entrar en ese estado. Cada vez que se
Estados entra al estado por medio de una transicin la accin de entrada se

ejecuta.

Una accin de salida aparece en la forma salida/accin_asociada.


INGENIERIA DE SOFTWARE I

Final

65

UNIVERSIDAD NACIONAL DE INGENIERIA

Cada vez que se sale del estado por una transicin de salida la accin de salida se ejecuta.

Una accin interna es una accin que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transicin a otro estado. Se indica en la forma

nombre_de_evento/accin_asociada.

66

INGENIERIA DE SOFTWARE I

UNIVERSIDAD NACIONAL DE INGENIERIA

18. Anlisis de riesgos

67

INGENIERIA DE SOFTWARE I