Fundamentos de Ingeniería de Software [Etapas]

Transcripción

1 Fundamentos de Ingeniería de Software [Etapas] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-I Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 1 / 63

2 Ingeniería de requerimientos Ingeniería de requerimientos I Los requerimientos para un producto de software o en general un sistema son descripciones del servicio que éste debe proporcionar, así como de sus restricciones de operación. Los requerimientos reflejan las necesidades de los clientes. La ingeniería de requerimientos consiste en identificar, analizar, documentar y verificar tales servicios y sus restricciones. Se distinguen dos niveles de abstracción para los requerimientos: Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 2 / 63

3 Ingeniería de requerimientos Ingeniería de requerimientos II Requerimientos del usuario Se escriben en lenguaje natural. Describen los servicios que esperan los usuarios. Describen las restricciones de operación. Gerentes del cliente Gerentes de los contratistas Arquitectos del sistema Usuarios finales del sistema Ingenieros del cliente Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 3 / 63

4 Ingeniería de requerimientos Ingeniería de requerimientos III Requerimientos del sistema Describen de forma detallada las funciones, los servicios y las restricciones operacionales del sistema que se implementarán. Puede formar parte del contrato Cliente Desarrolladores. Usuarios finales del sistema Ingenieros del cliente Arquitectos del sistema Desarrolladores de software Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 4 / 63

5 Ingeniería de requerimientos Ingeniería de requerimientos IV Ejemplo: Definición del requerimiento del usuario El Sistema de Administración de Pacientes elaborará mensualmente informes administrativos que revelen el costo de los medicamentos prescritos por cada clínica por mes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 5 / 63

6 Ingeniería de requerimientos Ingeniería de requerimientos V Ejemplo: Definición de los requerimientos del sistema El último día de cada mes se redactará un resumen de los medicamentos prescritos, su costo y las clínicas que los prescriben. El sistema elaborará automáticamente el informe que se imprimirá después de las 17:30 del mismo día. Por cada clínica, se realizará un reporte con los medicamentos prescritos, el número de prescripciones, las dosis y el costo total. Si los medicamentos están disponibles en diferentes dosis se harán informes por separado por cada dosis. Sólo los usuarios autorizados en la lista de control tendrán acceso a los informes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 6 / 63

7 Ingeniería de requerimientos Requerimientos funcionales I Tipos de requerimientos Describen los servicios que el sistema debe proveer. También se describe como debe reaccionar el sistema con determinadas entradas y su comportamiento en situaciones específicas. Se describen desde funciones generales hasta funciones más específicas. Se deben definir todos los servicios requeridos por el usuario. La ambigüedad puede causar muchos problemas a futuro. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 7 / 63

8 Ingeniería de requerimientos Requerimientos funcionales II Tipos de requerimientos Ejemplos 1 Un usuario podrá buscar en todas las clínicas las listas de citas. 2 El sistema elaborará diariamente, para cada clínica, la lista de pacientes que se espera asistan ese día. 3 Cada usuario del sistema deberá identificarse con su nombre de usuario y su contraseña. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 8 / 63

9 Ingeniería de requerimientos Requerimientos no funcionales I Tipos de requerimientos No se relacionan con los servicios que el sistema proporciona a sus usuarios. Describen la fiabilidad del sistema, su seguridad, su tiempo de respuesta, su disponibilidad, su costo de almacenamiento, entre otros. Se derivan de las restricciones presupuestales, políticas de la organización, interoperabilidad con otros sistemas, regulaciones de seguridad, legislación sobre privacidad, entre otros. Se pueden generalizar tres tipos de requerimientos no funcionales: Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 9 / 63

10 Ingeniería de requerimientos Tipos de requerimientos Requerimientos no funcionales II Requerimientos del producto Especifican o restringen el comportamiento del software. Ejemplos: Velocidad de ejecución del sistema Cantidad de memoria requerida Tasa aceptable de fallas Requerimientos de seguridad Requerimientos de usabilidad Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 10 / 63

11 Ingeniería de requerimientos Tipos de requerimientos Requerimientos no funcionales III Requerimientos de la organización Se derivan de las políticas y procedimientos en la organización del cliente y del proveedor de software. Se deviden en tres: Operacionales. Definen cómo se usará el sistema. Ambientales. Definen el entorno de operación del sistema. De desarrollo. Definen el lenguaje de programación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 11 / 63

12 Ingeniería de requerimientos Tipos de requerimientos Requerimientos no funcionales IV Requerimientos externos Se derivan de factores externos al sistema y su proceso de desarrollo. Se deviden en tres: Regulatorios. Establecen lo que debe hacer el sistema para ser aprobado. Éticos. Garantizan que el sistema opere conforme a la ley. Legales. Garantizan que el sistema será aceptable para los usuarios y en general para la sociedad. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 12 / 63

13 Ingeniería de requerimientos Requerimientos no funcionales V Tipos de requerimientos Metricas para los requerimientos no funcionales Eficiencia Tamaño Facilidad de uso Fiabilidad Robustez Portabilidad Transacciones/Segundo Tiempo de respuesta usuario/evento Tiempo de regeneración de pantalla Memoria necesaria Espacio de almacenamiento Tiempo de capacitación Tiempo medio para falla Tasa de ocurrencia de falla Probabilidad de indisponibilidad Tiempo de reinicio después de falla Probabilidad de corrupcion de datos Porcentaje de eventos que causan falla Sistemas Operativos Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 13 / 63

14 Ingeniería de requerimientos El documento de requerimientos I El documento de requerimientos Describe de manera oficial lo que deben implementar los desarrolladores del sistema. Incluye los requeirmientos de usuario y del sistema. Generalmente tienen acceso a este documento las siguientes personas: Clientes del sistema. Especifican los requerimientos y los verifican. Administradores. Les ayuda a planear una cotización para el sistema y su proceso de desarrollo. Ingenieros del sistema. Les ayuda a entender qué debe hacer el sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 14 / 63

15 Ingeniería de requerimientos El documento de requerimientos El documento de requerimientos II Ingenieros de prueba del sistema. Desrrollan las pruebas de validación del sistema. Ingenieros de mantenimiento del sistema. Les ayuda a comprender el sistema. A continuación se describe la estructura que debe poseer el documento de requerimientos: Prefacio Se debe describir el histórico de versiones así como la razón de ser de cada versión. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 15 / 63

16 Ingeniería de requerimientos El documento de requerimientos El documento de requerimientos III Índice Se debe incluir el índice normal, uno de diagramas, uno de funciones y en general uno de cada parte representativa del contenido. Introducción Describe la necesidad para haber creado el sistema. También describe de forma general las funciones del sistema. Finalmente describe cómo el sistema se ajusta a los objetivos de la empresa/cliente. Definición de requerimientos del usuario Se describen los requerimientos funcionales y los no funcionales. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 16 / 63

17 Ingeniería de requerimientos El documento de requerimientos El documento de requerimientos IV Arquitectura del sistema Se especifican los módulos del sistema y sus relaciones. Se deben describir las funciones de cada módulo. Se debe especificar cuáles de los componentes son reciclados. Especificación de requerimientos del sistema En esta parte se detallan tecnicamente los requerimientos funcionales y los no funcionales. Modelos del sistema Se muestran las relaciones entre los componentes del sistema y su entorno. Se muestran los modelos de objetos y los de los flujos de datos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 17 / 63

18 Ingeniería de requerimientos El documento de requerimientos El documento de requerimientos V Evolución del sistema Se describen las posibles ampliaciones al sistema que quedan a futuro. Apéndices Detallan los requerimientos de hardware que definen los rendimientos mínimo y óptimo del sistema. También detallan los requerimientos de bases de datos y la organización lógica de éstas. Glosario Define claramente los términos técnicos usados en el documento. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 18 / 63

19 Casos de uso I Ingeniería de requerimientos Casos de uso Los casos de uso son una técnica que consiste en la obtención de requerimientos. Describen los pasos y/o actividades involucrados en un proceso. Deben tenerse en cuenta a las personas o entidades que participarán en cada caso, es decir los actores. En cada caso, también se describirán las interacciones/relaciones entre el sistema y sus actores en respuesta a un evento. Existen tres tipos de relaciones básicas: Relación comunica (<<communicates>>): Establece una relación entre un actor y un caso de uso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 19 / 63

20 Casos de uso II Ingeniería de requerimientos Casos de uso Relación usa (<<uses>>): Establece una dependencia entre dos casos de uso, denotando la inclusión del comportamiento de un escenario en otro. Relación extiende (<<extends>>): Establece una dependencia entre dos casos de uso denotando que un caso de uso es una especialización de otro. Puntos importantes para la definición de un Caso de Uso: 1 Consecutivo. 2 Título. 3 Autor. 4 Fecha de creación 5 Fecha de última actualización. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 20 / 63

21 Casos de uso III Ingeniería de requerimientos Casos de uso 6 Actores. 7 Descripción. 8 Precondiciones. 9 Postcondiciones. 10 Flujo normal. 11 Flujos alternos. 12 Frecuencia de uso. 13 Reglas de negocio. 14 Requerimientos especiales 15 Notas. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 21 / 63

22 Casos de uso IV Ingeniería de requerimientos Casos de uso Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 22 / 63

23 Casos de uso V Ingeniería de requerimientos Casos de uso Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 23 / 63

24 Casos de uso VI Ingeniería de requerimientos Casos de uso Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 24 / 63

25 Casos de uso VII Ingeniería de requerimientos Casos de uso Un diagrama de casos de uso es un diagrama de comportamiento. UML Lenguaje de Modelado Unificado define una notación gráfica para representar casos de uso llamada modelo de casos de uso. NO confundir los diagramas de casos de uso con los casos de uso. Los diagramas de secuencias muestran la comunicación entre los actores/sistema en términos de secuencias de mensajes. Estos últimos son una descripción gráfica de la secuencia de pasos en cada caso de uso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 25 / 63

26 Casos de uso VIII Ingeniería de requerimientos Casos de uso Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 26 / 63

27 Casos de uso IX Ingeniería de requerimientos Casos de uso Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 27 / 63

28 Modelado del sistema Modelado del sistema I El modelado del sistema es el proceso que se lleva a cabo para hacer diseños abstractos de un sistema. Es posible diseñar modelos para sistemas existentes -describiendo sus fortalezas y debilidades- y para nuevos sistemas. Generalmente se utiliza algún tipo de notación gráfica como la UML. UML utiliza al menos 14 tipos de diagramas diferentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 28 / 63

29 Modelado del sistema Modelado del sistema II UML surgió en la decada de los 90 s y fue desarrollado por Grady Booch, Ivar Jacobson y Jim Rumbaugh de Rational Software -comprado por IBM en En 1997 fue adoptado por la OMG Object Management Group y en el 2000 por ISO International Organization for Standardization. En 2004 apareció una nueva versión denominada UML 2. En 2005 la OMG adopta la nueva versión de UML. Se puede distinguir entre cuatro tipos de modelos: estructurales, de comportamiento, de interacción y de contexto. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 29 / 63

30 Modelado del sistema Modelos estructurales I Modelos estructurales Un modelo estructural muestra la organización de un sistema en términos de sus componentes y las relaciones entre estos. Se clasifican en estáticos y dinámicos: Estáticos: Muestran la estructura del diseño del sistema. Dinámicos: Muestran la organización del sistema cuando se ejecuta. Son creados al momento de diseñar la arquitectura del sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 30 / 63

31 Modelado del sistema Modelos estructurales Modelos estructurales II Diagramas estructurales I Diagramas de clase: describen la estructura de un sistema, mostrandos las clases que componen al sistema, sus atributos y las relaciones entres estas. Diagramas de componentes: describen los componentes principales del sistema y las dependencias entre estos. Diagramas de estructuras compuestas: describen la estructura interna de una clase y las colaboraciones que su estructura hace posible. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 31 / 63

32 Modelado del sistema Modelos estructurales Modelos estructurales III Diagramas estructurales II Diagramas de despliegue: describen el hardware utilizado para las implementaciones del sistema y los entornos de ejecución utilizados sobre tal hardware. Diagramas de objetos: muestran una vista de la estructura de un ejemplo que ocurre en determinado momento. Diagramas de paquetes: muestran una división lógica del sistema a un nivel superior que los diagramas de componentes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 32 / 63

33 Modelado del sistema Modelos de comportamiento I Modelos de comportamiento Un modelo de comportamiento es un modelo dinámico. Muestra lo que debe ocurrir cuando un sistema responde ante un estímulo -datos o eventos-. Un modelo dirigido por datos muestra la secuencia de acciones derivadas del procesamiento de la entrada y la respectiva salida. Un modelo dirigido por un evento se basa en los estados por los que el sistema puede atravesar y cómo un evento puede causar la transición entres estados. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 33 / 63

34 Modelado del sistema Modelos de comportamiento II Modelos de comportamiento Diagramas de comportamiento Diagramas de actividades: describen los flujos del proceso del negocio paso a paso (diagrama de flujo). Diagramas de estado: describen los estados por los que puede atravesar el sistema. Diagramas de casos de uso: describen la funcionalidad del sistema en términos de sus actores. Diagramas de interacción: se enfocan en el flujo del control y de los datos de las cosas que estan siendo modeladas en el sistema. De comunicación De secuencia De resumen de la interacción De tiempo Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 34 / 63

35 Modelado del sistema Modelos de interacción I Modelos de interacción Los modelos de interacción implican todas las posibles interacciones en el sistema. Ejemplos son: Entradas de datos proporcionadas por los usuarios hacia el sistema. Interacciones entre el software a desarrollar y otras aplicaciones. Interacciones entre los componentes del propio sistema. Estan directamente implicados los casos de uso, pues presentarán a diferente nivel de detalle las interacciones en el sistema. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 35 / 63

36 Modelado del sistema Modelos de interacción II Modelos de interacción Diagramas de interacción Diagramas de comunicación: muestran las interacciones entre los diagramas de clases, de secuencias y de casos de uso. Diagrama general de interacción: es un resumen de los diagramas de comunicación. Diagramas de secuencia: muestran como se comunican los objetos en términos de mensajes. Diagramas de tiempo son diagramas de secuencia pero basados en las restricciones de tiempo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 36 / 63

37 Modelado del sistema Modelos de contexto I Modelos de contexto Un modelo de contexto define la frontera de un sistema. Se debe de especificar -con ayuda del cliente/usuarios- la nueva funcionalidad que aportará el sistema creado y la ya existente en el entorno donde se incorporará el nuevo software. Un modelo de contexto no necesariamente muestra el tipo de relación con los otros sistemas, pero tales relaciones pueden ser: De intercambio de datos. De compartición de servicios. Dentro de los modelos de contexto se encuentran los de contexto simple. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 37 / 63

38 Modelado del sistema Modelos de contexto II Modelos de contexto Un modelo de contexto simple sólo muestra el sistema a desarrollar y los sistemas de su entorno. Figura : Sistema de información de pacientes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 38 / 63

39 Modelado del sistema Modelos de contexto III Modelos de contexto Un modelo de contexto empresarial describe los procesos humanos y automatizados que se usan en sistemas particulares. Figura : Proceso de detención involuntaria de pacientes. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 39 / 63

40 Diseño orientado a objetos Diseño orientado a objetos I Un sistema orientado a objetos está formado por objetos que poseen un determinado estado y éste permite operaciones sobre si mismo. El estado del objeto debe estar encapsulado de modo que no se pueda acceder directamente a él. Los objetos son creados dinámicamente a partir de definiciones de clase. La ventaja en este tipo de diseños es que el cambiar el diseño de un objeto o agregarle servicios, no afectará a otros objetos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 40 / 63

41 Diseño orientado a objetos Diseño orientado a objetos II Es relativamente fácil realizar un mapeo entre las entidades del mundo real y los objetos que formarán parte del sistema. Las etapas en el proceso de un diseño orientado a objetos son: Comprender y definir el contexto e interfaces del sistema. Diseñar la raquitectura del sistema. Identificar los principales objetos del sistema. Desarrollar los modelos de diseño. Especificación de la interfaz. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 41 / 63

42 Diseño orientado a objetos Contexto e interacciones del sistema Contexto e interacciones del sistema I La primer etapa consiste en comprender las relaciones entre el sistema que se diseñará y su entorno. Se deben delimitar las fronteras del sistema. Se debe especificar la naturaleza de las relaciones n El enfoque debe ser lo mas abstracto posible. Aquí es donde se utiliza UML para modelar el contexto y las interacciones del sistema, así como los casos de uso. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 42 / 63

43 Diseño orientado a objetos Contexto e interacciones del sistema Contexto e interacciones del sistema II Figura : Contexto de un sistema para una estación meteorológica. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 43 / 63

44 Diseño orientado a objetos Diseño arquitectónico I Diseño arquitectónico Los reultados de la etapa anterior sirven como base para diseñar la arquitectura del sistema. Tal información debe ser combinada con los principios de diseño arquitectónico de software. Existen cuatro tipos de arquitecturas básicas: En capas Cliente servidor De repositorio De tubería y filtro Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 44 / 63

45 Diseño orientado a objetos Diseño arquitectónico II Diseño arquitectónico Arquitectura en capas En una arquitectura en capas los elementos del sistema están separados de modo que pueden ser modificados de forma independiente. Sin embargo las capas tienen una funcionalidad relacionada. Las capas inferiores representan a los servicios que podrán ser utilizados por las capas superiores. Esta arquitectura se puede utilizar cuando el desarrollo se puede dividir entre varios equipos de trabajo o cuando existe un requerimiento de seguridad multinivel. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 45 / 63

46 Diseño orientado a objetos Diseño arquitectónico III Diseño arquitectónico Ventajas Permite la remodelación o cambio por completo de capas, mientras se conserve la interfaz. Permite la inserción de capas que fortalezcan la funcionalidad de la interfaz. Desventajas En la práctica es difícil hacer una separación entre capas. El rendimiento suele ser bajo. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 46 / 63

47 Diseño orientado a objetos Diseño arquitectónico IV Diseño arquitectónico Figura : Arquitectura en capas Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 47 / 63

48 Diseño orientado a objetos Diseño arquitectónico Diseño arquitectónico V Arquitectura de repositorio Esta arquitectura describe como son compartidos los datos utilizados por un sistema. En esta arquitectura los componentes no interactúan directamente entre sí, sino a través del repositorio de datos. Esta arquitectura se puede utilizar cuando se desarrollarán sistemas que utilizarán grandes volúmenes de información que deben ser perdurables. También pueden utilizarse en sistemas que serán activados en el momento que sean agregados datos al repositorio. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 48 / 63

49 Diseño orientado a objetos Diseño arquitectónico Diseño arquitectónico VI Ventajas Los componentes pueden ser independientes y no necesaitan saber de la existencia de otros. Si los datos están en un mismo lugar, pueden crearse respaldos con facilidad. Los cambios hechos en un componente se pueden propagar hacia los demás a través de la actualización de los datos. Desventajas Los problemas en el repositorio afectarán a todo el sistema. Es posible que haya ineficiencias en la comunicación. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 49 / 63

50 Diseño orientado a objetos Diseño arquitectónico VII Diseño arquitectónico Figura : Arquitectura de repositorio Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 50 / 63

51 Diseño orientado a objetos Diseño arquitectónico Diseño arquitectónico VIII Arquitectura cliente-servidor La funcionalidad del sistema se organiza en servicios, y cada servicio es gestionado de forma independiente. Los clientes acceden a dichos servicios a través de servidores. Se puede utilizar cuando los datos o servicios serán accedidos desde diferentes ubicaciones geográficas. Tambien se sugiere cuando la carga de un sistema es variable, pues los servidores podrán ser replicados. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 51 / 63

52 Diseño orientado a objetos Diseño arquitectónico IX Diseño arquitectónico Ventajas Los servidores pueden ser distribuidos a través de una red. Es posible que funcionalidades generales estén disponibles para todos los clientes, por lo que no se tienen que realizar implementaciones separadas. Desventajas El rendimiento es impredecible pues dependerá de la carga de la red y de cada sistema. Si los servidores pertenecen a diferentes propietarios puede haber problemas administrativos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 52 / 63

53 Diseño orientado a objetos Diseño arquitectónico X Diseño arquitectónico Figura : Arquitectura Cliente-Servidor Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 53 / 63

54 Diseño orientado a objetos Diseño arquitectónico Diseño arquitectónico XI Arquitectura de tubería y filtro En este tipo de arquitectura los datos fluyen de un componente a otro para su procesamiento. Cada componente suele realizar un tipo de transformación hacia datos. Se puede utilizar en actividades de procesamiento de datos, donde las entradas se procesan en etapas separadas con el objetivo de generar salidas relacionadas. Los sistemas embebidos pueden ser diseñados bajo este tipo de arquitectura. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 54 / 63

55 Diseño orientado a objetos Diseño arquitectónico Diseño arquitectónico XII Ventajas Esta arquitectura puede coincidir con la estructura de muchos procesos empresariales. Puede implementarse de forma secuencial o concurrente. Desventajas El formato para la transferencia de datos debe acordarse de antemano. Puede resultar difícil utilizar nuevos módulos o realizar cambios sobre los existentes si es que las estructuras de datos son incompatibles. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 55 / 63

56 Diseño orientado a objetos Diseño arquitectónico XIII Diseño arquitectónico Figura : Arquitectura de tubería y filtro Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 56 / 63

57 Diseño orientado a objetos Identificación de clases de objetos Identificación de clases de objetos I El objetivo es identificar los puntos escenciales sobre los objetos para tener una idea más clara de lo que se debe implementar. La especificación de los casos de uso será de gran ayuda para identificar los objetos y las operaciones del sistema. Cómo identificar las clases de objetos en un sistema orientado a objetos? En base a la descripción -en lenguaje natural- del sistema considerar: sustantivos objetos y atributos, verbos operaciones y servicios. Realizar las definiciones de objetos en base a entidades tangibles (roles, eventos, ubicaciones, unidades organizacionales). Realizar un análisis en base a escenarios. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 57 / 63

58 Diseño orientado a objetos Desarrollo de los modelos de diseño Desarrollo de los modelos de diseño I Se realizan los modelos de diseño del sistema revisados previamente: Estructurales De interacción De comportamiento De contexto Los modelos más importantes a considerar son: Los estructurales. Objetivo: Representar los agrupamientos lógicos de objetos en el sistema. Los de secuencia. Objetivo: Ilustrar las secuencias de interacciones de objetos. Los de estados. Objetivo: Mostrar los cambios de estado de los objetos en respuesta a sus eventos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 58 / 63

59 Diseño orientado a objetos Especificación de la interfaz I Especificación de la interfaz Una interfaz es una especificación de los componentes que serán utilizados entre los diferentes componentes del diseño. El desarrollo de interfaces permite el desarrollo de los objetos y subsistemas en paralelo. El diseño de una interfaz proporciona la especificación del detalle de como interacturán los objetos del sistema. Su especificación en UML es similar al de las clases normales. Un diseño de interfaz no debe incluir detalles de la representación de los datos. Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 59 / 63

60 Diseño orientado a objetos Especificación de la interfaz II Especificación de la interfaz Un mismo objeto puede tener muchas interfaces. <<interfaz>> Nombre-interfaz metodo 1 (arg 1,..., arg n ). metodo m (arg 1,..., arg n ) Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 60 / 63

61 Diseño orientado a objetos Especificación de la interfaz III Especificación de la interfaz Figura : Diagrama de clases con interfaces para un juego de poker cliente-servidor Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 61 / 63

62 Diseño orientado a objetos Especificación de la interfaz IV Especificación de la interfaz Figura : Especificación de la interfaz GameInt en Java Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 62 / 63

63 Diseño orientado a objetos Especificación de la interfaz V Especificación de la interfaz Figura : Implemetación de la clase Game Sergio Luis Pérez (UAM CUAJIMALPA) Curso de fundamentos de ing. de software 63 / 63