INGENIERIA DE SOFTWARE. Dr. Mario Rossainz López Fac. de Cs. de la Computación Benemérita Universidad Autónoma de Puebla Primavera 2017

Transcripción

1 INGENIERIA DE SOFTWARE Dr. Mario Rossainz López Fac. de Cs. de la Computación Benemérita Universidad Autónoma de Puebla Primavera 2017

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40 Metodología de Desarrollo de Software 1.- Planeación del Proyecto de Desarrollo de Sw 2.- Análisis de Requerimientos 3.- Diseño Arquitectónico o Estructural 4.- Diseño Funcional o de Comportamiento 5.- Implementación o Codificación 6.- Pruebas 7.- Mantenimiento

41 1. Planeación del Proyecto de Desarrollo de Software a) DEFINICION DEL PROBLEMA: i) Enunciado definitivo del problema a resolver empleando terminología del cliente ii) Identificación de subsistemas de: Equipo de Cómputo, lenguajes y herramientas de programación, de personal o equipo de trabajo

42 1. Planeación del Proyecto de Desarrollo de Software b) DESARROLLO DE UNA ESTRATEGIA DE SOLUCION: i) Esbozar varias estrategias de solución ii) Realizar un estudio de la factibilidad para cada estrategia iii) Adoptar y por tanto recomendar al cliente una estrategia de solución indicando el porque se rechazar las demas

43 1. Planeación del Proyecto de Desarrollo de Software c) ADECUACION DEL PRODUCTO SOFTWARE EN LA PLANEACION: i) Definición del modelo del ciclo de vida adoptado para el producto software ii) Determinación del uso de herramientas a utilizar por fase iii) Establecer estimaciones de costo para el proyecto iv) Establecer un cronograma de actividades para el desarrollo del producto software v) Identificación de fuentes de información

44 2. Análisis de Requerimientos CASOS DE USO EN UML: a) Identificar y listar el o los posibles actores que intervendrán en el uso del sistema software que se esta analizando b) Identificar y listar los posibles casos de uso que pueden estar presentes en la utilización del sistema software por parte de los actores definidos en el inciso anterior. c) Con los actores y casos de uso identificados, crear el correspondiente Diagrama de Casos de Uso que captura lo que el sistema software debe hacer. d) Para cada caso de uso explicar en lenguaje natural la secuencia normal que un actor seguiría al utilizarlos. Así mismo, explicar también las excepciones que pueden ocurrir por parte del actor.

45 2. Análisis de Requerimientos Ejemplo: Un cajero automático A priori se distinguen 3 clases de actores: Cliente Sistema del Banco Operador Y un conjunto de formas de uso: Sacar_Dinero Transferencia Depositar_Dinero Administración

46 2. Análisis de Requerimientos Ejemplo: Un cajero automático Sacar_Dinero Transferencia Cliente Sistema del Banco Depositar_Dinero Administración Operador

47 2. Análisis de Requerimientos SECUENCIA NORMAL DE EJECUCION: Ejemplo: Un cajero automático Se visualiza un mensaje de bienvenida en pantalla: El usuario inserta la tarjeta en el cajero. El cajero lee el código de la banda magnética de la tarjeta y verifica si es aceptable, en caso positivo, pide el código del usuario. Esperando el código: El usuario introduce el código. Si el código es correcto, el cajero pide al usuario que seleccione el tipo de transacción deseada. Esperando el tipo de transacción: El usuario selecciona la función de sacar dinero, el cajero le pide al usuario que teclee la cantidad deseada. Esperando la cantidad deseada: El usuario teclea la cantidad que quiere sacar, el cajero envía la petición al sistema del banco. Se prepara el recibo. Se expulsa la tarjeta. Se imprime el recibo. Se entrega el dinero.

48 2. Análisis de Requerimientos EXCEPCIONES: Ejemplo: Un cajero automático La tarjeta no es aceptada: Si la tarjeta no es aceptada, se expulsa emitiendo un sonido. Código incorrecto: Se emite un mensaje dando la oportunidad de que el usuario vuelva a introducir el código. No autorizado para sacar dinero: Si el sistema del banco no autoriza sacar dinero se emite un mensaje informando al usuario y expulsando la tarjeta. No hay dinero: Si el cajero no dispone de la cantidad pedida se emite un mensaje y se expulsa la tarjeta. Cancelar: En cualquier momento el usuario puede cancelar la transacción.

49 2. Análisis de Requerimientos Transacción de Tarjeta Ejemplo: Un cajero automático «uses» «uses» «uses» Sacar_Dinero Depositar_Dinero Transferencia «extends» Recoger Estadística La asociación utiliza: Representa la relación que se da entre un caso de uso abstracto y uno concreto. La asociación extiende: permite que un caso de uso se inserte en otro. Esta relación se utiliza para modelar partes opcionales de los casos de uso, secuencias separadas y diferentes casos de uso que son insertados de manera especial

50 3. Diseño arquitectónico o estructural DIAGRAMA DE CLASES EN UML: a) Identificación de clases u objetos en base a diversos criterios de clasificación: Cosas Tangibles, Interacciones, Roles o Papeles, Incidentes, Unidades Organizacionales, Lugares, posiciones geográficas o físicas, Especificaciones, etc. b) Selección de clases u objetos definitivos que serán utilizados para modelar la parte arquitectónica o esquelética del sistema software c) Construir el diagrama de clases empezando por una asociación y terminando por agregar: roles, multiplicidad, navegación, estructura y comportamiento, herencia, agregaciones, etc.

51 3. Diseño arquitectónico o estructural Ejemplo: Un Sistema de Bibliotecas El problema es modelar un sistema de biblioteca con los siguientes requerimientos: El sistema soportará operaciones de búsqueda y préstamo de material bibliográfico que incluye libros, proyectos y revistas. Los usuarios de la biblioteca podrán realizar consultas sobre el material bibliográfico Cada usuario puede tener prestado un número máximo de elementos Cada tipo de material tiene diferentes periodos de préstamo (por ejemplo, los libros tienen un máximo de 7 días en tanto que los proyectos no deberán superar 15 días) Si se devuelve un elemento después de la fecha prevista, la biblioteca multará al usuario con diferentes montos económicos dependiendo del tipo de material.

52 3. Diseño arquitectónico o estructural Ejemplo: Un Sistema de Bibliotecas Socio -Nombre : string -Direccion : string -Telefono : string +ConocerDatos() : void +ConocerMaterialPrestado() : void +ConocerMultas() : void Material -titulo : string -idioma : string +ConocerDatos() : void +Prestarse() : void +Devolverse() : void +CalcularFechaDevolucion() : Date +CalcularMulta() : double Sistema de Biblioteca -nombre : string -ubicacion : string -area : string -tipo : string +ConocerMaterial() : void +PrestarMaterial() : bool +DevolverMaterial() : bool +BuscarMaterial() : bool +ObtenerInformacion() : string Libro -ISBN : string -editorial : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double Proyecto -Registro : int -Nota : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double Revista -numero : int -volumen : signed int -area : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double

53 3. Diseño arquitectónico o estructural Ejemplo: Un Sistema de Bibliotecas 0..* 1 Socio -Nombre : string -Direccion : string -Telefono : string +ConocerDatos() : void +ConocerMaterialPrestado() : void +ConocerMultas() : void Material -titulo : string -idioma : string +ConocerDatos() : void +Prestarse() : void +Devolverse() : void +CalcularFechaDevolucion() : Date +CalcularMulta() : double 0..* 1 Sistema de Biblioteca -nombre : string -ubicacion : string -area : string -tipo : string +ConocerMaterial() : void +PrestarMaterial() : bool +DevolverMaterial() : bool +BuscarMaterial() : bool +ObtenerInformacion() : string Libro -ISBN : string -editorial : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double Proyecto -Registro : int -Nota : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double Revista -numero : int -volumen : signed int -area : string +CalcularFechaDevolucion() : Date +CalcularMulta() : double

54 4. Diseño Funcional o de Comportamiento de clases a) Modelado del Comportamiento de las clases: Uso de los Diagramas de Transición de Estados de UML para modelar el funcionamiento de una sola clase de objetos. b) Modelado del Comportamiento del Sistema Software: Uso de los diagramas de interacción de clases para identificar las posibles comunicaciones entre los objetos de las clases definidas

55 4. Diseño Funcional o de Comportamiento de clases Ejemplo: Un coche 1 Coche Motor de Arranque Freno Transmisión Acelerador

56 4. Diseño Funcional o de Comportamiento de clases Diagrama de Transición de Estados de la clase Motor de Arranque Ejemplo: Un coche (Punto Muerto)Girar llave Soltar Llave Off Arranque On Apagar

57 4. Diseño Funcional o de Comportamiento de clases Diagrama de Transición de Estados de la clase Transmisión Ejemplo: Un coche Punto Muerto Meter reversa Meter punto muerto Marcha Atras Meter velocidad Meter punto muerto Marcha Adelante subir subir Primera Segunda Tercera bajar bajar Marcha Adelante

58 4. Diseño Funcional o de Comportamiento de clases Ejemplo: Un sistema de compras por internet

59 4. Diseño Funcional o de Comportamiento de Diagrama de Interacción (colaboración) de clases clases Ejemplo: Un sistema de compras por internet

60 4. Diseño Funcional o de Comportamiento de clases Diagrama de Actividades Ejemplo: Funcionamiento del sistema de las agencias de viaje

61 5. Implementación o Codificación Modelado de Paquetes: Un paquete es un contenedor de elementos (colección de clases o componentes). Las flechas punteadas indican dependencia entre los paquetes * 1 primitivas de graficado * 1 * 1 Figuras Geométricas Prismas Componentes de Dibujo

62 5. Implementación o Codificación Modelado de Componentes: Proporcionan las vistas necesarias para especificar la naturaleza física de un producto software. Los diagramas de componentes de UML se utilizan para modelar la organización y dependencia de componentes que tienen que ver con el código fuente, con el código ejecutable o ambos. Primitivas de Graficado Punto.java Partícula.java Línea.java

63 5. Implementación o Codificación Figuras Geométricas Figuras.java Triangulo.java Rectangulo.java

64 5. Implementación o Codificación Prismas PrismaRec.java Cubo.java PrismaTrian.java PrismaCuad.java

65 5. Implementación o Codificación Componentes de Dibujo Ventana.java Color.java DibujaFigura.java DibujaPrisma

66 Herramientas CASE: Microsoft Visio 2003

67 Herramientas CASE: Microsoft Visio 2003

68 Herramientas CASE: Rational Rose

69 Herramientas CASE: Rational Rose

70 Herramientas CASE: Rational Rose

71 Conclusiones UML utiliza el modelado visual como una forma de resolver problemas usando modelos que se basan sobre las ideas del mundo real UML es un Lenguaje de Modelado, por tanto se compone de una notación con sintaxis predefinida y semántica en sus componentes UML es un Lenguaje robusto, utilizado para llevar a cabo un Análisis y Diseño Orientado a Objetos en base al modelado visual La implementación de un sistema o producto software requiere de tres elementos fundamentales: una notación, un proceso y una herramienta

72 Referencias Bibliográficas 1. Booch, Grady. Análisis y Diseño Orientado a Objetos con Aplicaciones. Addison-Wesley/Diaz de Santos. Segunda Edición Pressman, Roger S. ingeniería de software: Un enfoque práctico. McGraw-Hill. Cuarta Edición Schmuller Joseph. Aprendiendo UML en 24 horas. Prentice Hall. Primera Edición. México Jacobson, Booch, Rumbaugh. El proceso Unificado de Desarrollo Software. Adison Wesley. Segunda Edición. Madrid C. Bock and J. Odell, A Foundation For Composition, Journal of Objectoriented Programming, October 1994.

73 Referencias Bibliográficas 6. Grady Booch, Jim Rumbaugh, and Ivar Jacobson, Unified Modeling Language User Guide, ISBN: , Addison Wesley, est. publication December See 7. S. Cook and J. Daniels, Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice-Hall Object-Oriented Series, D. D Souza and A. Wills, Input for the OMG Submission, 9. M. Fowler with K. Scott, UML Distilled: Applying the Standard Object Modeling Language, ISBN , Addison-Wesely,

74 Referencias Bibliográficas 10. M. Griss, Domain Engineering And Variability In The Reuse-Driven Software Engineering Business. Object Magazine. Dec (See D. Harel, Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming 8 (1987), D. Harel and E. Gery, Executable Object Modeling with Statecharts, Proc. 18th Int. Conf. Soft. Eng., Berlin, IEEE Press, March, 1996, pp