Desarrollo de Proyectos de Software Ago-Dic10

8/7/2019 Desarrollo de Proyectos de Software Ago-Dic10

http://slidepdf.com/reader/full/desarrollo-de-proyectos-de-software-ago-dic10 1/151

Desarrollo de Proyectos de SoftwareDesarrollo de Proyectos de Software

Ingeniería en Sistemas Computacionales

Salvador Gurrola Velazquez

[email protected]




y Aportación de la asignatura al perfil del

egresado

Desarrolla aplicaciones de software de cualquierdominio.

y OBJETIVO GENERAL DEL CURSO

El estudiante diseñará y construirá unproyecto de software conforme a los

requerimientos establecidos en el dominio delproyecto de software.



Desarrollo de Proyectos de SoftwareDesarrollo de Proyectos de Softwarey Conceptos Introductorios.

1.1 La arquitectura de 4+1 vistas.

1.2 Desarrollo orientado aobjetos.

1.3 Diagramación.Tipos decontroladores.

y Diseño orientado a objetos.

2.1 Diseño del sistema en base a

procesos.

2.1.1 Actividades y casos de uso.

2.1.2 Interfaces de usuario.

2.2 Diseño de la lógica.

2.2.1 Clases y Objetos.

2.2.2 Interacción.

2.2.3 Estados y Transiciones.

Construcción.3.1 Despliegue de componentes yarquitectónico.3.2 Técnicas de desarrollo de lasarquitecturas de referencia endiferentes dominios.3.2.1 Los modelos de componentes.

3.2.2 Arquitectura de referencia parasistemas de tiempo real fuentede alimentación.3.2.3 Arquitectura de referencia parasistemas móviles con conexióna Internet.3.2.4 Arquitectura de referencia para

sistemas de información.3.2.5 Arquitectura de referencia paraambientes virtuales deaprendizaje.3.2.6 Arquitecturas de referencia paralíneas de productos.



Desarrollo de Proyectos de SoftwareDesarrollo de Proyectos de Softwarey Pruebas de software.

4.1 Definiciones.

4.1.1 Prueba, caso de prueba,

defecto, falla, error, verificación,

validación.

4.1.2 Relación entre defecto-fallaerror.

4.1.3 Pruebas estructurales,

funcionales y aleatorias.

4.1.4 Documentación del diseño de

las pruebas.

4.2 Proceso de pruebas.

4.2.1 Generar un plan de pruebas.

4.2.2 Diseñar pruebas especificas. 4.2.3 Tomar configuración del

software a probar.

4.2.4 Configurar las pruebas.

4.2.5 Evaluar resultados.

4.2.5.1 Depuración.

4.2.5.2 Análisis de errores.

4.3 Técnicas de diseño de casos depruebas.4.4 Enfoque práctico recomendado parael diseño de casos.4.5 Estrategias de aplicación de laspruebas.4.5.1 De unidad.4.5.2 De integración.

4.5.3 Del sistema.4.5.4 De aceptación

Implantación y mantenimiento.5.1 Implantación e Integración de casosde uso y componentes de software.5.2 Mantenimiento del software.



Desarrollo de Proyectos de SoftwareDesarrollo de Proyectos de Softwarey

Agenda Semana1 Agosto -27 Conceptos Introductorios Semana2 Septiembre -3 Semana3 Septiembre - 10

Semana4 Septiembre- 17 Diseño orientado a objetos. Semana5 Septiembre ² 24 Semana6 Octubre - 1

Semana7 Octubre - 8 Semana8 Octubre - 15 Construcción. Semana9 Octubre ² 22 Semana10 Octubre - 29 Semana11 Noviembre- 5 Semana12 Noviembre - 12 Pruebas de software. Semana13 Noviembre - 19 Semana14 Noviembre ² 26 Semana15 Diciembre - 3 Implantación y mantenimiento. Semana16 Diciembre - 10

Semana17 Diciembre ² 17 Examenes de Regularizacion y Extraordinarios




y Evaluación Asistencia 10%

Examenes 70%

Proyecto 20%




y Proyecto Diseño, implantación y pruebas de un sistema

computacional en las diferentes

organizaciones de la localidad.



Desarrollo de Proyectos de SoftwareDesarrollo de Proyectos de Softwarey FUENTESDE INFORMACIÓN

1. Fowler, Martin.UML Gota a Gota Addison Wesley. 1999

2. Larman, Craig. UML y patrones. Pearson. 1999

3. Bruegge Bernd .Ingeniería de Software Orientada a Objetos. Prentice

Hall. 2001.

4. Braude, Eric. Ingeniería de Software Una perspectiva Orientada a

Objetos . Alfaomega. 2003.

5. Meyer, Bertrand.C onstrucción de Software Orientada a Objetos.

Prentice Hall.1999.

6. Oestereich Bernd.Developing Software with UML, Object-Oriented

Analysis and Desing in Practice. Addison Wesley. 1999.

7. Reed R.Paul.Developing Applications with Visual Basic and UML.

Addison Wesley. 2001.

8. Jacobson,Ivar.El Proceso unificado de desarrollo de Software. Addison

Wesley. 2000.

9.Humphrey, Watts S. Introducción al Proceso Software Personal.

Addison Wesley. 2000

10. Sommerville, Ian. Ingeniería de Software. Prentice Hall. 2001.

11. Pressman Roger S. Ingeniería del Software, 5/ E. Mc.Gaw-Hill. 2001.

12. Laudon & Laudon 8/E. Management Information Systems. Prentice-Hall.

2003.



UnidadUnidad I I

ConceptosConceptos IntroductoriosIntroductorios..

y 1.1 La arquitectura de 4+1 vistas.

y 1.2 Desarrollo orientado a objetos.y 1.3 Diagramación.





LaLa arquitecturaarquitectura de 4+1 vistasde 4+1 vistasy 1. Arquitectura Lógica (Logical

Architecture) Soporta el análisis y la especificaciónde los requisitos funcionales: lo que el sistema deberíaproporcionar en términos de servicios a sus usuarios.

y El sistema se descompone en un conjunto de

abstracciones clave tomadas mayormente del dominiodel problema, en forma de objetos o clases.y En esta vista se usan comúnmente los diagramas de

clases, los de interacción y objetos.y Notación: La notación más usada es UML, y dentro de

esta diagramas de clases y paquetes.y Estilo: El estilo más usado para la vista lógica es el

Orientado a Objetos.



LaLa arquitecturaarquitectura de 4+1 vistasde 4+1 vistasy 2. Arquitectura de Procesos (Process Architecture) Se

tratan algunos requisitos no funcionales.y E jecución, disponibilidad, tolerancia a fallos, integridad, etc.y Esta vista también especifica que hilo de control ejecuta cada

operación identificada en cada clase identificada en la vista

lógica.y La vista se centra por tanto en la concurrencia y

distribución de procesos.y Notación: La notación más usada es UML, y dentro de esta

diagramas estados, actividad y similares.y Estilo: pueden encajar varios estilos. Por ejemplo, tomando la

taxonomía de Garlan y Shaw (1993), pueden usarse tuberíasy filtros (pipes and filtres) o Cliente ² Servidor (convariantes de múltiples clientes ² simple servidor y múltiplesclientes ² múltiples servidores).



LaLa arquitecturaarquitectura de 4+1 vistasde 4+1 vistasy 3. Arquitectura de Desarrollo (DevelopmentArchitecture) La vista de desarrollo o

despliegue se enfoca en la organización de los módulos software en el entorno dedesarrollo.

y El software es empaquetado en pequeños trozos (librerías de programa, subsistemas,componentes, etc.), los subsistemas se organizan en capas jerárquicas, y cada capaproporciona una interfaz bien definida a sus capas superiores

y La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad dedesarrollo, gestión del software (reparto de requisitos, trabajo del equipo), evaluación de

costes, planificación, monitorización del progreso del proyecto, reutilización, portabilidad,seguridad y restricciones impuestas por las herramientas o por el lenguaje deprogramación

y Esta organización del software se suele apoyar en diagramas de módulos o de subsistemasque muestran las relaciones de exportación (export) e importación (import). Y destacarque podrá describirse la vista de desarrollo por completo solamente después de haberidentificado todos los elementos software.

y Notación: La notación más usada es UML, y dentro de esta diagramas de componentes y

paquetes.y Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de

desarrollo.y Una regla de diseño es que un subsistema puede solamente depender de subsistemas en

la misma capa o en las menores.y Esto minimiza las dependencias entre módulos a favor de una más simple estrategia capa ²

capa.



LaLa arquitecturaarquitectura de 4+1 vistasde 4+1 vistasy 4. Arquitectura Física (Physical Architecture) La

vista física se centra en los requisitos no funcionales,tales como la disponibilidad del sistema, la fiabilidad(tolerancia a fallos), ejecución y escalabilidad.

y Y también presenta cómo los procesos, objetos, etc.,

corresponden a nodos de roceso:y Componentes: nodos de proceso.y Conectores: LAN, WAN, bus, etc.y Contenedores: subsistemas físico Varias

configuraciones físicas pueden usarse.y La correspondencia de el software a los nodos debe

ser altamente flexible y tener el mínimo impacto enel código fuente.



LaLa arquitecturaarquitectura de 4+1 vistasde 4+1 vistasy 5. Escenarios (Scenarios) La vista de

escenarios corresponde con instancias decasos de uso que unifican todas las vistas.

y

Así, desde casos de uso se debiera poderhacer una trazabilidad a todos loscomponentes del sistema de software,viendo, por ejemplo, que máquinas, o

clases, o componentes, o procesos, sonlos responsables de que el sistema cubrauna cierta funcionalidad.





Programación Orientada a ObjetosProgramación Orientada a Objetos

y Características principales del Diseño Orientadoa Objetos:

Los objetos son abstracciones del mundo real oentidades del sistema que se administran entreellas mismas

Los objetos son independientes y encapsulan elestado y la representación de información

La funcionalidad del sistema se expresa entérminos de servicios de los objetos

Las áreas de datos compartidas son eliminadas.Los objetos se comunican mediante paso deparámetros

Los objetos pueden estar distribuidos y puedenejecutarse en forma secuencial o en paralelo



Programación Orientada a ObjetosProgramación Orientada a Objetos

y Programación Orientada a Objetos En la Programación Procedural la unidad básica es el

procedimiento, el cual se comporta como una caja negra puederecibir unos parámetros de entrada, los procesa y puededevolver datos de salida .

En un programa con procedimientos los datos pueden sercomunes o globales a todos ellos, y no existe un control másdetallado de ellos, o no existe una entidad encargada de su ciclode vida. No existen formas de esconder funcionalidades ni decontrolar accesos.

En la Programación Orientada a Objetos la unidad básica es elobjeto. Un objeto tiene atributos y métodos que le dan

comportamiento. Cada objeto controla sus propios datos y secomunica con otros objetos a través de sus métodos (mensajes).Los objetos encapsulan su funcionamiento mostrando a otrosobjetos sólo lo necesario.



UMLUMLy UML (Unified Modeling Language) es un lenguaje que permite

modelar, construir y documentar los elementos que forman unsistema software orientado a objetos.

y Se ha convertido en el estándar de facto de la industria,debido a que ha sido concebido por los autores de los tresmétodos más usados de orientación a objetos: Grady Booch,Ivar Jacobson y Jim Rumbaugh.

y Estos autores fueron contratados por la empresa RationalSoftware Co. para crear una notación unificada en la quebasar la construcción de sus herramientas CASE.

y En el proceso de creación de UML han participado, no

obstante, otras empresas de gran peso en la industria comoMicrosoft, Hewlett-Packard, Oracle o IBM, así como gruposde analistas y desarrolladores.



ModelosModelosy Un modelo representa a un sistema software

desde una perspectiva específica.y Al igual que la planta y el alzado de una figura en

dibujo técnico nos muestran la misma figura vista

desde distintos ángulos, cada modelo nos permitefijarnos en un aspecto distinto del sistema.y 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.



DiagramaciónDiagramación



DiagramasDiagramas UMLUMLy La figura debajo muestra la taxonomía de los 13 diagramas UML, como está definido por la

especificación de UML 2.0 de Grupos de Desarrollo de Objetos.y Como se puede ver, hay dos grupos mayoritarios de diagramas:

y diagramas Estructurales los cuales muestran una vista estática del modelo; y

y diagramas de Comportamiento los cuales muestran una vista dinámica del modelo.



modelo del proceso de negociomodelo del proceso de negocioy E

l Modelo del Proceso del Negocio describe tanto el comportamiento como el flujo deinformación dentro de una organización o sistema. Como un modelo de actividad denegocio, éste captura los eventos significantes, entradas, recursos, procesos y salidasasociadas con los procesos de negocio relevantes.



modelomodelo deldel dominiodominioy Un Modelo del dominio es un modelo conceptual de alto nivel, que define objetos físicos y abstractos, en

un área de interés para el Proyecto.y Se puede usar para documentar relaciones entre ellos y responsabilidades de clases conceptuales (es

decir, las clases que representan el concepto de un grupo de cosas en lugar de Clases que definen unobjeto de programación). Esto también es útil para definir los términos de un dominio.



DiagramaDiagrama deldel PaquetePaquetey

Los Diagramas de Paquetes se usan para reflejar la organización de los paquetes y suselementos, y para proveer una visualización de sus correspondientes nombres de espacio.



DiagramaDiagrama deldel PaquetePaquete



DiagramaDiagrama deldel PaquetePaquete



Modelo de ProyectoModelo de Proyectoy El Modelo del proyecto detalla el plan del proyecto global, fases, hitos y requisitos de recursos

para el proyecto actual.y Los administradores del proyecto pueden usar Microsoft Project para asignar recursos a los

elementos, medidas de riesgo y esfuerzo y para estimar el tamaño del proyecto.



DiagramaDiagrama dede AnálisisAnálisisy

Un diagrama del Análisis es un diagrama de actividad simplificado, que se usa para capturarprocesos del negocio del alto nivel y modelos tempranos del comportamiento y de loselementos del sistema. Es menos formal que algunos otros diagramas, pero proporcionabuenos medios de capturar las características y las necesidades esenciales del negocio.



modelo de requisitosmodelo de requisitosy El Modelo de requisitos es un catálogo estructurado de requerimientos del usuario final y las

relaciones entre ellos. La Administración de requisitos se puede usar para definir elementos derequerimientos, vincular requerimientos para los elementos del modelo, vincular requerimientos juntos en una jerarquía y reportar requerimientos.



DiagramaDiagrama dede RequisitosRequisitosy

Un diagrama de Requisitos es un diagrama personalizado usado para describir los requisitoso características de un sistema como un modelo visual.

y Los requisitos se definen usando elementos de requisitos (elementos personalizados de tipo

Requisito). Para ver la descripción detallada de un requisito, haga doble clic en el elementopara mostrar sus propiedades. Los elementos de requisito se pueden vincular para loscasos de uso y componentes en el sistema para mostrar como se cumple un requisito delsistema en particular.



DiagramaDiagrama PersonalizadoPersonalizadoy

Un diagrama Personalizado es un diagrama de Clase extendido que se usa para capturar requisitos, interfaces de usuario o modelos de diseño personalizado.

y El ejemplo de abajo refleja un diagrama de requisitos. Los elementos requisito se puedenvincular a los casos de uso y a los componentes en el sistema para ilustrar cómo secumple el requisito en un sistema en particular.



Diagrama de CapasDiagrama de Capas



modelo de casos de uso(999)modelo de casos de uso(999)y El Modelo de casos de uso describe la funcionalidad de un sistema en términos de Casos de uso.

Cada Caso de uso representa una sola interacción repetida que el usuario o "actor"experimenta cuando usa el sistema, acentuando la perspectiva de los usuarios del sistema y lasinteracciones.



DiagramaDiagrama dede CasosCasos dede UsoUsoy Un diagrama de C asos de Uso captura las interacciones de los casos de uso y los actores.

Describe los requisitos funcionales del sistema, la forma en la que las cosas externas(actores) interactúan a través del límite del sistema y la respuesta del sistema.



DiagramaDiagrama dede ActividadesActividadesy Los diagramas de actividades se usan para modelar el comportamiento de un sistema, y la manera

en que éste comportamiento está relacionado con un f lu jo global del sistema. Se usan loscaminos lógicos que sigue un proceso basado en varias condiciones, concurrencia en el

proceso, los datos de acceso, interrupciones y otras alternativas del camino lógico

para construir un proceso, sistema o procedimiento.



DiagramaDiagrama dede SecuenciaSecuenciay Un diagrama de Secuencia es una representación estructurada de comportamiento como una serie de

pasos secuenciales a lo largo del tiempo.Se usa para representar el flu jo de traba jo, elpaso de mensa jes y cómo los elementos en general cooperan a lo largo del tiempo paralograr un resultado.

y � Cada elemento de la secuencia está ordenado en una secuencia horizontal, con paso de mensajeshacia atrás y hacia adelante entre los elementos.

y � Un elemento actor se puede utilizar para representar al usuario iniciando el flujo de eventos.

y � Los elementos estereotipados, tales como límite, control y entidad, se puede utilizar para ilustrarpantallas, controladores e ítems de bases de datos, respectivamente.

y

� Cada elemento tiene una línea de trazos llamada línea de vida, en donde este elemento existe ypotencialmente toma parte en las interacciones.



DiagramaDiagrama dede SecuenciaSecuencia



DiagramasDiagramas dede ComunicacionesComunicaciones ((formalmenteformalmenteDiagramaDiagrama dede ColaboracionesColaboraciones))y Un diagrama de C omunicaciones muestra las interacciones entre los elementos en tiempo de

ejecución en forma semejante a un diagrama de Secuencia. No obstante, los diagramas deComunicación se usan para visualizar relaciones inter-objetos, mientras que los diagramasde Secuencia son más efectivos para visualizar procesamiento a lo largo del tiempo.

y Los diagramas de Comunicaciones emplean asociaciones ordenadas y etiquetadas para ilustrarel procesamiento. Es importante la numeración para indicar el orden y el anidamiento

del procesamiento. Un esquema de numeración podría ser 1, 1.1, 1.1.1, 1.1.2, 1.2, etc.Comienza un nuevo segmento de números para una nueva capa de procesamiento, y sería

equivalente a la invocación de un método.



Diagrama de Descripción de la InteracciónDiagrama de Descripción de la Interaccióny Los diagramas de Descripción de

las Interacciones muestran lacooperación entre otrosdiagramas de interacciónpara refle jar el flu jo decontrol que responde a unpropósito abarcativo. Comolos Diagramas de Descripciónde las Interacciones son una

variante de los diagramas deactividades, la mayor parte de lanotación es similar, al igual queel proceso de construcción deldiagrama. Los puntos dedecisión, bifurcación, unión,puntos de inicio y final son losmismos. En lugar de actividadesse usan elementos

rectangulares. Hay dos tipos deestos elementos:

y Los elementos de interacciónmuestran un diagrama deinteracción en línea , el cualpuede ser un diagrama deSecuencias, Comunicaciones, deTiempos, o de Descripción delas Interacciones.



DiagramaDiagrama dede MáquinaMáquina de Estadode Estadoy Un diagrama de Máquina de estados ilustra cómo un elemento (a menudo una clase) se puede

mover entre estados, clasificando su comportamiento de acuerdo con los disparadores detransiciones y las guardas de restricciones. Otros aspectos de los diagramas de Máquinas deEstados describen y explican el movimiento y el comportamiento.



DiagramaDiagrama dede MáquinaMáquina de Estadode Estado



DiagramaDiagrama dede TiemposTiemposy El diagrama de Tiempo define el comportamiento de los diferentes objetos con una escala de

tiempo. Provee una representación visual de los objetos cambiando de estado e interactuando a lo

largo del tiempo.y Puede usar diagramas de tiempos para definir componentes de software dirigidos por hardware o

embebidos; por ejemplo, aquellos usados en un sistema de inyección de combustible, un controlador demicroondas. También puede usar diagramas de tiempo para especificar procesos de negocio dirigidospor tiempo.



modelo de clasesmodelo de clasesy El Modelo de clase es un modelo riguroso y lógico del sistema de software bajo

construcción.y Las clases generalmente tienen una relación directa con el código fuente y otros

artefactos de software que se pueden agrupar juntos en componentes ejecutables.



DiagramaDiagrama dede ClasesClasesy El diagrama de C lases captura la estructura lógica del sistema - las clases y cosas que

constituyen el modelo -. Es un modelo estático, describiendo lo que existe y qué

atributos y comportamiento tiene, más que cómo se hace algo. Los diagramas deClases son los más útiles para ilustrar las relaciones entre las clases e interfaces. Lasgeneralizaciones, las agregaciones y las asociaciones son todas valiosas para reflejar laherencia, la composición o el uso y las conexiones respectivamente.



DiagramaDiagrama dede ObjetosObjetosy Un diagrama de Objetos está relacionado de cerca con un diagrama de Clases, con la

diferencia de que éste describe las instancias de los objetos de clases en un punto

en el tiempo. Esto podría parecer similar al diagrama de Estructura Compuesta, quemodela el comportamiento en tiempo de ejecución; la diferencia es que el diagrama deObjetos ejemplifica al diagrama de Clases estático, mientras que los diagramas deEstructura Compuesta refleja las arquitecturas diferentes de sus contrapartes estáticas.Los diagramas de Objetos no presentan arquitecturas que varíen de sus correspondientesdiagramas de Clases, pero reflejan la multiplicidad y los roles a los que las clases

instanciadas podrían servir.E

llos son muy útiles en la comprensión de diagramas de Clasescomplejos, al crear diferentes casos en los que se aplican las relaciones y las clases. Undiagrama de Objetos puede ser también un tipo de diagrama de Comunicaciones, el cualmodela también las conexiones entre pares de objetos y además las secuencias de eventosa lo largo de cada camino.



modelo de los componentesmodelo de los componentesy El Modelo del componente define como las clases, artefactos y otros elementos de ba jo

nivel se agrupan en componentes de alto nivel, y las interfaces y conexiones entreellos.

y Los componentes son artefactos de software compilados que trabajan juntos para proveer elcomportamiento requerido dentro de las restricciones de operación definidas en el modelo derequisitos.



DiagramaDiagrama dede ComponentesComponentesy Un diagrama de C omponentes ilustra los fragmentos de software, controladores embebidos,

etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel deabstracción más elevado que un diagrama de clase - usualmente un componente seimplementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloquesde construcción, como así eventualmente un componente puede comprender una granporción de un sistema.



modelo de base de datosmodelo de base de datosy El Modelo de base de datos describe la información que debe ser almacenada y recuperada como

parte del sistema completo.y Normalmente esto referirá a los modelos de base de datos relacional que describen las tablas y

datos en detalle y permitirá la generación de scripts DDL para crear e instalar base de datos.



EsquemaEsquema de Base dede Base de DatosDatos



Diagrama de la Interfaz del UsuarioDiagrama de la Interfaz del Usuarioy Los Diagramas de la Interfaz del Usuario usados para imitar visualmente la interfaz del

usuario del sistema usando formas, controles y etiquetas.

y El siguiente diagrama de la Interfaz del Usuario de ejemplo, las formas, controles y etiquetasse organizan en el diagrama para describir su apariencia. Los elementos UI también sepueden rastrear a otros elementos del modelo vinculando el UI con la implementación debase.



modelo de desplieguemodelo de desplieguey El Modelo de despliegue describe cómo y dónde un sistema se desplegará.

y

Las máquinas físicas y los procesadores son representados por nodos, y la construcción internase puede describir embebiendo nodos y artefactos.

y Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicaciónse guía por el uso de especificaciones de despliegue.



DiagramaDiagrama dede DespliegueDesplieguey Un diagrama de Despliegue muestra cómo y dónde se desplegará el sistema. Las máquinas

físicas y los procesadores se representan como nodos, y la construcción interna puede serrepresentada por nodos o artefactos embebidos. Como los artefactos se ubican en losnodos para modelar el despliegue del sistema, la ubicación es guiada por el uso de lasespecificaciones de despliegue.



Modelo de MantenimientoModelo de Mantenimientoy El Modelo de mantenimiento permite una representación visual de incidencias que surgen durante

y después del desarrollo del producto de software.y El modelo puede ser mejorado con la integración de elementos de cambios y pruebas.



DiagramaDiagrama dede MantenimientoMantenimientoy Un diagrama de Mantenimiento es un diagrama personalizado usado para describir pedidos de

cambios e items de incidencia dentro de un modelo del sistema.y El siguiente ejemplo ilustra un diagrama de mantenimiento de ejemplo. Los elementos de cambios,

tareas e incidencias se pueden luego vincular a otros elementos del modelo en el sistema parailustrar como necesitan ser modificados, fijados o actualizados.

y Los modelos de Mantenimiento proveen extensiones al modelo UML y permiten laadministración de cambios de los items de cambios, y los elementos del modelo que requierenhacer los cambios en ellos



modelo de pruebasmodelo de pruebasy El Modelo de pruebas describe y mantiene un catálogo de pruebas, planes de prueba

y resultados que se ejecutan en comparación con el modelo actual.



UnidadUnidad II II DiseñoDiseño orientadoorientado aa objetosobjetos..

2.1 Diseño del sistema en base a

procesos.x 2.1.1 Actividades y casos de uso.x 2.1.2 Interfaces de usuario.

2.2 Diseño de la lógica.x 2.2.1 Clases y Objetos.

x 2.2.2 Interacción.

x 2.2.3 Estados y Transiciones.





Diagrama de casos de uso 9/6 1,2

Diagrama de Secuencia 9/6 3,4

Diagrama de Colaboracion 9/7 5,6

Diagrama de Estados 9/7 7,8 Diagrama de Clases 9/8 9,10

Diagrama de Objetos 9/8 11



Teoria de Patrones de diseno Daniel 9/20

Patrón DELEGATION Mauro 9/20

Patrón INTERFACE Elizabeth 9/20

Patrón MARKER INTERFACE Manuel 9/21

Patrón SINGLETON Ana L 9/21

Patrón FACTORY METHOD Jorge 9/21 PatrónADAPTER Lourdes A 9/22 Patrón FAÇADE Patricia 9/22 Patrón OBSERVER Edgar 9/22 Patrón STRATEGY Julio C 9/23 P

atrón ITERATOR Adiel 9/23



DiseñoDiseño orientadoorientado aa objetosobjetos..y El Diseño Orientado a los Objetos (DOO)

crea una representación del problemadel mundo real y la hace corresponder conel ámbito de la solución, que es el software.

y A diferencia con otros métodos de diseño, elDOO produce un diseño que interconectaobjetos de datos y operaciones de

procesamiento para esos objetos, deforma que se modulariza la información y elprocesamiento, en lugar de aislar elprocesamiento.



DiseñoDiseño orientadoorientado aa objetosobjetos..

y Todos los métodos de diseño intentandesarrollar software basándose en: �Abstracción

� Ocultamiento de información � Modularidad

y El DOO proporciona un mecanismo quepermite al diseñador consigue estas trescaracterísticas sin dificultad.



ObjetosObjetos,, operacionesoperaciones yy mensa jesmensa jes

y Para conseguir un DOO, tenemos que

establecer un mecanismo para: � Representar la estructura de datos

� Especificar el proceso

� Realizar el procedimiento de invocación




yObjeto: Componente del mundo realque se hace corresponder con elsoftware.

y En un Sistema de Información basado enComputador, un objeto es un

producto o consumidor de

información, o un elemento deinformación.




y Operaciones, métodos o servicios:Procesos a los que se le permitetransformar estructuras de datos.




y Mensajes: Peticiones que se realizan a losobjetos para que realicen alguna de susoperaciones.

y Las operaciones contienenconstrucciones procedimentales y de

control, que se invocan mediante unmensaje.



AspectosAspectos dede diseñodiseño

y Descomponibilidad:Facilidad con la que un método de diseñoayuda al diseñador a descomponer un problema en subproblemasmás sencillos.

y Componibilidad:Grado en el que un método de diseño permitela reutilizabilidad de módulos.

y Comprensibilidad:Facilidad para comprender un componentedel programa sin tener que hacer referencia a otros módulos.

y Continuidad:Capacidad de realizar cambios en un programa yque esos cambios afecten a un número mínimo de módulos.

y Protección:Característica arquitectónica que reduce lapropagación de errores.



PrincipiosPrincipios dede diseñodiseño

y principios de diseño para arquitecturasmodulares:

� Unidades modulares � Pocas interfaces � Interfaces pequeñas (acoplamiento

débil) � Interfaces explícitas � Ocultamiento de información



PrincipiosPrincipios dede diseñodiseño

y Para conseguir un acoplamiento débil, se debeminimizar el número de interfaces entre módulos yminimizar la cantidad de información que se mueve através de una interfaz.

y Siempre que los módulos tengan que comunicarsetiene que hacerlo de forma clara, mediante interfacesexplícitas, y no mediante una zona global de datos.

y El principio de ocultamiento de información seconsigue cuando toda la información del módulo estáoculta para el acceso desde el exterior, a menos quela información se defina explícitamente de formapública.



DescripcionesDescripciones de losde los objetosobjetos

y La descripción del diseño de un objeto (una instancia de unaclase o de una subclase) está compuesta de dos partes:

y Descripción de la interfaz: Establece la interfaz del objeto,definiendo los mensajes que puede recibir el objeto y las

operaciones que puede realizar cuando el objeto recibe elmensaje.

y Descripción de la implementación: Muestra los detallesde cada una de las operaciones implicadas comoconsecuencia de la recepción de un mensaje. Los detalles de

implementación incluyen información sobre la parte privadadel objeto, es decir, los detalles de las estructuras de datos ylos detalles procedimentales que describen las operaciones.



METODOSDE DISEÑO ORIENTADOSA OBJETOSMETODOSDE DISEÑO ORIENTADOSA OBJETOS

y Debemos comprender la diferencia entreel Análisis Orientado a Objetos, que esuna actividad de clasificación, y el

Diseño Orientado a Objetos, que definelos objetos que se derivan de cada

clase.



Pasos del DiseñoOrientado a ObjetosPasos del DiseñoOrientado a Objetos

y 1) Definición del problema

y 2) Desarrollo informal de la forma deprocesamiento para la realización del software

y 3) Formalización de la forma de procesamiento a) Identificar los objetos y sus atributos b) Identificar las operaciones de los objetos c) Establecer las interfaces que muestren las

relaciones entre los objetos y las operaciones d) Crear un diseño detallado que proporcione una

descripción de la implementación de los objetos



DEFINICIÓNDE CLASES Y DE OBJETOSDEFINICIÓNDE CLASES Y DE OBJETOS

y La aplicación de los principios y métodos de análisis de requisitos permiteal analista y al diseñador llevar a cabo dos subpasos necesarios. a) Descripción del problema b) Análisis y aclaración de las limitaciones conocidas

y La realización del software del problema del mundo real debe describirse

de forma sencilla y correcta para que permita a los ingenieros del softwareque trabajan en el proyecto comprender el problema de forma sencilla yuniforme.

y El cometido del AOO es el de aislar todos los nombres y frases del textoexplicativo del procesamiento que describe que es lo que ha de realizar elsistema.

y Esta primera selección nos puede ayudar a definir las clases, subclases yobjetos del sistema. a) Un nombre común suele representar una clase de objetos (una abstracción de

datos), como puede ser automóvil.

b) Un nombre propio suele representar una instancia de una clase, como puede ser Juan.



PROCESODEL ANÁLISIS Y DISEÑO ORIENTADOA LOSPROCESODEL ANÁLISIS Y DISEÑO ORIENTADOA LOSOBJETOS (99)OBJETOS (99)

y El resultado del diseño orientado aobjetos es una jerarquía de clases.

y Los elementos iniciales de un DOO sonlos propios objetos, y posteriormente, amedida que se van identificando aspectos

comunes, los objetos se van agrupando enclases, que a su vez serán subclases declases más abstractas.



PasosPasos del DOOdel DOO

y Esencialmente, el DOO consta de cuatro pasosfundamentales: a) Identificación y definición de objetos y clases b) Organización de relaciones entre clases

c)E

xtracción de estructuras en una jerarquía declases d) Construcción de bibliotecas de clases reutilizables

y Como en todas las fases de Ingeniería del

Software, el DOO es cíclico, es decir, losdiseñadores comienzan definiendo un conjuntode clases, que se amplían, modifican, ..., y vuelta aempezar.



Identificación y definición de objetosIdentificación y definición de objetos

y El principal problema del desarrollo de un sistema orientado aobjetos es encontrar los objetos en la fase de AOO y DOO.

y El método que utilizaremos para la identificación de objetos es elpropuesto por Booch en 1983, que dio origen al métodogramatical.

y Esta metodología sugiere que se comience con una descripcióntextual del sistema deseado y que el diseñador vea: �A los nombres como posibles identificadores de las clases de los

objetos �A los verbos como posibles métodos

y La lista resultante de clases (nombres) y métodos (verbos) seutilizará para comenzar el proceso de diseño.



Directrices para la identificación y definición de clases yDirectrices para la identificación y definición de clases y

métodosmétodos

� Modelar con clases las entidades que ocurren de forma naturalen el problema

� Diseñar métodos con una sola finalidad � Diseñar un método nuevo antes de ampliar uno existente

� E

vitar métodos extensos � Guardar como instancia los datos necesitados por más de unmétodo o por una subclase

� El diseñador debe trabajar para obtener una biblioteca declases.

y Además, para evitar la creación de clases innecesarias odeclaración de clases que no lo sean, una clase debe ofreceruna serie de servicios a objetos de un tipo determinado.



Directrices para la identificación y definición de clases yDirectrices para la identificación y definición de clases y

métodosmétodos

y Una clase se debería crear cuando:

� La nueva clase represente una abstracción

significativa del problema � Es probable que los servicios que

proporciona sean utilizados por otras clases.

� Su comportamiento sea complejo.

� Si se representara como un método de otraclase, pocos usuarios de ésta lo invocarían.



Definición y organización de clasesDefinición y organización de clases

y La identificación y definición de objetos es sólo el primerpaso en el diseño de un Sistema OO.

y La abstracción es la tarea continua de un diseñador OO.

y Una vez definidos los objetos, el paso siguiente consiste enobservar características comunes para crear abstracciones anivel de clase, pero no existe ninguna metodología formalpara la realización de estas abstracciones.

y La definición de una clase para generar múltiples instanciasde un objeto ofrece la primera visión del poder de laabstracción.

















ClasificacionClasificacion

y Analicemos la siguiente definición de requerimientos:

El <<sistema de tratamiento de información documental>> esun gestor de <<documentos>>, de tal manera que puedanclasificar en uno o varios <<índices>>, recuperar para sumodificación, visualizar, para su consulta, reclasificar, archivar y

destruir. El <<sistema>> procesa la petición del <<usuario>>,

devolviendo un mensaje e indicando el éxito o el fracaso de lapetición.

y

De una manera general hemos indicado entrecomillas los sustantivos y en cursiva los verbos. Deesta forma hemos identificado los objetos principalesde la aplicación y las operaciones asociadas a cadauno de los objetos.




y Observe el siguiente diagrama.y traducido los requerimientos a un conjunto de objetos.

y Estos están inconexos entre sí, pero aplicando la<<lógica>> podemos ver las relaciones que existenentre ellos.




y Sin salirnos de las especificaciones de la aplicación, vemos que existen lasasociaciones que aparecen en la siguiente figura:

y Como podemos observar, algunas asociaciones cíclicas como Indice <->Documento. Estas asociaciones pueden simplificarse.

y También existen otras implícitas que examinaremos más adelante, como Usuario->Documento->Indice.




y Observemos gráficamente las asociaciones que mantienen losobjetos entre sí en la siguiente figura



ClasificacionClasificacion (999)(999)

y LA RELACIONDE HERENCIA.

y A continuación vamos a centrarnos en la relación de herencia.

y Como ya sabemos ésta puede agrupar objeto son similares característica obien especializar objetos a partir de una genérico. Observemosnuevamente los requerimientos de nuestro sistema:



AsociacionesAsociaciones

y Las asociaciones entre dos clases se representan mediante una

línea que las une. La línea puede tener una serie de elementosgráficos que expresan características particulares de la asociación.

y A continuación se verán los más importantes de entre dichoselementos gráficos.

y El nombre de la asociación es opcional y se muestra como un texto

que está próximo a la línea.y Se puede añadir un pequeño triángulo negro sólido que indique la

dirección en la cual leer el nombre de la asociación. En el ejemplode la Figura se puede leer la asociación como ́ Director mandasobre Empleadoµ.



MultiplicidadMultiplicidad

y 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 conuna instancia de la otra clase. Puede expresarse de las siguientes formas:

· Con un número fijo: 1.

· Con un intervalo de valores: 2..5.

· Con un rango en el cual uno de los extremos es un asterisco. Significa que esun intervalo abierto. Por ejemplo, 2..* significa 2 o más.

· Con una combinación de elementos como los anteriores separados porcomas: 1, 3..5, 7, 15..*.

· Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o

más).



RolesRoles

y Para indicar el papel que juega una clase en una asociación se puede

especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.



AgregaciónAgregación

y El símbolo de agregación es un diamante colocado en el extremo en el que

está la clase que representa el ́ todoµ.



ClasesClasesAsociaciónAsociación

y 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.y Tanto la línea como el rectángulo de clase representan el mismo elemento

conceptual: la asociación.

y Por tanto ambos tienen el mismo nombre, el de la asociación.

y Cuando la clase asociación sólo tiene atributos el nombre suele ponersesobre la línea (como ocurre en el ejemplo de la Figura).

y Por el contrario, cuando la clase asociación tiene alguna operación oasociación propia, entonces se pone el nombre en la clase asociación y sepuede quitar de la línea.



AsociacionesAsociacionesNN--AriasArias

y 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. Si se muestramultiplicidad en un rol, representa el número potencial de tuplas deinstancias en la asociación cuando el resto de los N-1 valores están fijos.

y En la Figura 12 se ha impuesto la restricción de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque lamultiplicidad de ́ Equipoµ es 1 en la asociación ternaria.



HerenciaHerencia

y 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µ.y Si se tiene una relación de herencia con varias clases subordinadas, pero en

un diagrama concreto no se quieren poner todas, esto se representamediante puntos suspensivos.

y En el ejemplo de la Figura, sólo aparecen en el diagrama 3 tipos dedepartamentos, pero con los puntos suspensivos se indica que en el

modelo completo (el formado por todos los diagramas) la clase´Departamentoµ tiene subclases adicionales, como podrían ser ́ RecursosHumanosµ y ́ Producciónµ.



Conceptos básicos de la OxOConceptos básicos de la OxO

y Polimorfismo

Polimorfismo significa que la misma

operación puede comportarse

diferentemente sobre distintas clases. Por ejemplo, la operación "mover" ejemplo

puede comportarse diferentemente sobre

una clase llamada Ventana y una clase

llamada Piezas_ajedrez.



Conceptos básicos de la OxOConceptos básicos de la OxOy Polimorfismo Paramétrico: Se obtiene cuando una

función trabaja uniformemente sobre un rango detipos; esos tipos normalmente exhiben unaestructura común y puede comportarse de maneradistinta para cada tipo.

y Polimorfismo de Inclusión: Es un polimorfismoutilizado por modelos de subtipos y herencia. Eneste tipo de polimorfismo un objeto puedepertenecer a clases diferentes que nonecesariamente son disjuntas.




y Polimorfismo por Overloading: En estecaso el mismo nombre se utiliza para

denotar diferentes funciones, y el

contexto se utiliza para decidir cualfunción se debería ejecutar para una

invocación particular del nombre.




y Polimorfismo por Coerción: Es unaoperación semántica que convierteargumentos a los tipos esperado por unafunción, en una situación que de otra formaresultaría en un tipo de error.

y La coerción puede estar dadaestáticamente, insertándoseautomáticamente entre argumentos y

funciones a tiempo de compilación opueden tener que determinarsedinámicamente, con pruebas a tiempos deejecución sobre los argumentos.



Conceptos básicos de laConceptos básicos de la OxOOxO (999)(999)

y Her enciay La herencia consiste en el compartir

atributos y métodos entre clasesbasándose en una relación jerárquica.

y Una clase puede definirse ampliamente yredefinirse sucesivamente en subclasesmás refinadas.

y Cada subclase que se incorpora, hereda

todas las propiedades de su superclase yadiciona sus propias y únicas propiedades.

C bá d l O OC bá d l O O




Elementos capaces de ser her edados

y Herencia Estructural.

y Herencia de Comportamiento (herencia de métodos).





Nombre

Persona

Empleado Estudiante

Secretaría

Director

Año de experiencia

Idiomas

Dependencia

Cargo

DenominaciónCarrera

Edad

Dirección

Sexo

Profesión

Dependencia





y Tipos de Herencia:

y Simple.

y Múltiple

C bá i d l O OC bá i d l O O




Nombre

Persona

Empleado Estudiante

Secretaría

Director

Año de experiencia

Idiomas

Dependencia

Cargo

DenominaciónCarrera

Edad

Dirección

Sexo

Profesión

Dependencia





y Definición de Herencia Múltiple: Unaclase puede heredar rasgos de más

de una superclase. Una clase con

más de una superclase es llamadaclase junta. Un rasgo de una clase

ancestro que se encuentra más de

una vez a lo largo de una ruta solo se

hereda una vez.





Vehícul

Vehícul Terrestres Vehícul s Acuáticos

CarrosVehículos

Anf i iosBote




Conceptos básicos de la OxOConceptos básicos de la OxOy Encadenamiento Dinámico:Una de las ventajas que promueve el estilo

de programación orientada por objeto es lacaracterística del encadenamientodinámico, también llamadoencadenamiento tardío. En efecto, no setendrían sistemas orientados por objeto sinesa poderosa capacidad.

y Simplemente, la declaración

encadenamiento dinámico significa que elsistema encadenará una rutina a unselector para un método particular que estáimplantado sobre un objeto clase.

PP dd Di ñDi ñ



PatronesPatrones dede DiseñoDiseño

P tP t dd Di ñDi ñ



PatronesPatrones dede DiseñoDiseño

y � El diseño OO es difícil y el diseño de softwareorientado a objetos reutilizable lo es aún más.

y � Los diseñadores expertos no resuelven losproblemas desde sus principios; reutilizansoluciones que han funcionado en el pasado. ² Se encuentran patrones de clases y objetos de

comunicación recurrentes en muchos sistemasorientados a objetos.

² Estos patrones resuelven problemas de diseñoespecíficos y hacen el diseño flexible y reusable.

D fi i ióD fi i ió dd t ót ó



DefiniciónDefinición de unde un patrónpatrón

y Alexander(arquitecto/urbanista)y Cada patrón describe un problema que ocurre

una y otra vez en nuestro entorno y describetambién el núcleo de la solución al problema, deforma que puede utilizarse un millón de vecessin tener que hacer dos veces lo mismo.

Definición de un patrón deDefinición de un patrón de



pp

diseñodiseñoy [Gamma]y Un patrón de diseño es una descripción de

clases y objetos comunicándose entre sí adaptada para resolver un problema de diseñogeneral en un contexto particular.

I t d ióI t d ió



IntroducciónIntroducción

y � Es un tema importante en el desarrollo desoftware actual: permite capturar la experiencia

y � Busca ayudar a la comunidad dedesarrolladores de software a resolverproblemas comunes, creando un cuerpoliterario de base

² Crea un lenguaje común para comunicar

ideas y experiencia acerca de los problemas ysus soluciones

y � El uso de patrones ayuda a obtener unsoftware de calidad (reutilización y

extensibilidad)

El tEl t dd t ót ó



ElementosElementos de unde un patrónpatrón

y � Nombre: describe el problema dediseño.

y � El problema: describe cuándo aplicar

el patrón.y � La solución: describe los elementos

que componen el diseño, sus relaciones,

responsabilidades y colaboración.

ClasificaciónClasificación de losde los patronespatrones




y Según su propósito:y ² De creación: conciernen al proceso de

creación de objetos.

y ² De estructura: tratan la composiciónde clases y/o objetos.

y ² De comportamiento: caracterizan las

formas en las que interactúan y repartenresponsabilidades las distintas clases uobjetos.




pp

GoFGoF (gang of Four) [Gamma](gang of Four) [Gamma]

PatronesPatrones dede diseñodiseño fundamentalesfundamentales



PatronesPatrones dede diseñodiseño fundamentalesfundamentales

y Son patrones que no aparecen la tabladefinida por Gamma, pero se utilizanhabitualmente:� DELEGATION

� INTERFACE

� MARKER INTERFACE

PatrónPatrón DELEGATIONDELEGATION




y Utilidad: Cuando se quiere extender y reutilizar la

funcionalidad de una clase SIN UTILIZAR LAHERENCIA

y Venta jas:

� En vez de herencia múltiple

� Cuando una clase que hereda de otra quiere

ocultar algunos de los métodos heredados � Compartir código que NO se puede

heredar




ElEl problemaproblema

y - El lenguaje utilizado NO PERMITE HERENCIA MÚLTIPLE

y - La clase C no desea TODOS los

métodos de B




LaLa soluciónsolución




ImplementaciónImplementación

Class C extends A {B objB;

C ( ) { // En la constructora se puede crear obj. de B

objB=new B();

}void b1( )

{

objB.b1( );

}

«.

PatrónPatrón INTERFACEINTERFACE



UtilidadUtilidad yyVenta jasVenta jas

y Utilidad Definir un comportamiento independiente de donde

vaya a ser utilizado

y Venta jas

Desacople entre comportamiento y clase.Realización de clases ´Utilitiesµ




ElEl problemaproblema




LaLa soluciónsolución




ImplementaciónImplementación




EjemploEjemplo

PatrónPatrón MARKER INTERFACEMARKER INTERFACE



UtilidadUtilidad yyVenta jasVenta jas

y � Utilidad ² Sirve para indicar atributos semánticos de una

clase.

y �Ventajas: ² Se puede preguntar si un objeto pertenece a una

clase de un determinado tipo o no.

² Habitualmente se utiliza en clases de utilidades quetienen que determinar algo sobre objetos sin asumirque son instancias de una determinada clase o no.








EjemploEjemplo

y En Java hay clases ́ serializablesµ, ́ cloneablesµ,etc. Para ello, basta con que implementen lasinterfaces Serializable, Cloneable, etc.




GoFGoF (gang of Four) [Gamma](gang of Four) [Gamma]



PatrónPatrón SINGLETONSINGLETON



ImplementaciónImplementacióny

² E

l constructor de la clase DE

BE

SE

R PRIVADOy ² Se proporciona un método ESTÁTICO en la clase que

devuelve LA ÚNICA INSTANCIA DE LA CLASE:getInstance()































ElementosElementos ComunesComunes aaTodosTodos loslos DiagramasDiagramas

UnidadUnidad IIIIDi ñDi ñ i t di t d bj tbj t



DiseñoDiseño orientadoorientado aa objetosobjetos..

2.1 Diseño del sistema en base a procesos.

2.1.1 Actividades y casos de uso.

2.1.2 Interfaces de usuario.

2.2 Diseño de la lógica. 2.2.1 Clases y Objetos.

2.2.2 Interacción.

2.2.3 Estados y Transiciones.



Documents

Desarrollo de Proyectos de Software Ago-Dic10