Taller de Herramientas de Productividad

Vicerrectoría Académica Cuaderno de Apuntes – 2013

Cuaderno de Apuntes de uso exclusivo e xclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Estimado Estudiante de AIEP, en este Cuaderno de Apuntes, junto a cada Aprendizaje Esperado que se te presenta y que corresponde al Módulo que cursas, encontrarás “Conceptos, Ideas Centrales y Aplicaciones” que reforzarán el aprendizaje que debes lograr. Esperamos que estas Ideas Claves entregadas a modo de síntesis te orienten en el desarrollo del saber, del hacer y del ser. Mucho Éxito.Dirección de Desarrollo Curricular y Evaluación VICERRECTORÍA ACADÉMICA AIEP



Estimado Estudiante de AIEP, en este Cuaderno de Apuntes, junto a cada Aprendizaje Esperado que se te presenta y que corresponde al Módulo que cursas, encontrarás “Conceptos, Ideas Centrales y Aplicaciones” que reforzarán el aprendizaje que debes lograr. Esperamos que estas Ideas Claves entregadas a modo de síntesis te orienten en el desarrollo del saber, del hacer y del ser. Mucho Éxito.Dirección de Desarrollo Curricular y Evaluación VICERRECTORÍA ACADÉMICA AIEP



Módulo: TALLER DE HERRAMIENTAS DE PRODUCTIVIDAD UNIDAD 1 : Proceso de desarrollo orientado a objetos enfocado en el análisis orientado a objetos (ADO) Aprendizaje Esperado: Aplicar el proceso de desarrollo de software a través de las herramientas esenciales para el proceso de software y fases de un ciclo de vida, con análisis orientado a objetos. El análisis y diseño orientado a objetos (ADO) es un enfoque de d e la ingeniería la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue. 1.1 Proceso de desarrollo de software. Un sistema informático se compone de HW y SW. En relacion al HW, su producción se realiza sistemáticamente y la base de conocimiento para el desarrollo se define claramente. Respecto al SW, su construcción y resultados siempre se han puesto en duda debido a ciertos problemas, como son: Los sistemas no responden a las expectativas de los usuarios.     



Los programas “fallan” con cierta frecuencia.

Los costos del software son difíciles de prever y normalmente superan las estimaciones. La modificación del software es una tarea difícil y costosa. El software se suele presentar fuera del plazo establecido y con menos prestaciones de las consideradas inicialmente. El aprovechamiento óptimo de los recursos (personas, tiempo, dinero, herramientas, etc.) no suele cumplirse.

Problemas comunes en el desarrollo de software son: Escasa o tardía validación con el cliente. Inadecuada gestión de los requisitos. No existe medición del proceso ni registro de datos históricos. Estimaciones imprevistas de plazos y costos. Excesiva e irracional presión en los plazos. Escaso o deficiente control en el progreso del proceso de desarrollo. No se hace gestión de riesgos formalmente. No se realiza un proceso formal de pruebas. p ruebas. No se realizan revisiones técnicas formales e inspecciones de código.         

Ingeniería del software: “La aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software”.

El libro Ingenieria de Software de Pressman define la Ingeniería de Software como “una tecnología multicapa”, como aparece en la Figura 1.

Figura 1: Capas de la Ingeniería de Software.











Cualquier disciplina de ingeniería debe estar sustentada sobre la calidad. Gestionar con calidad permite tener una cultura de mejoras de procesos. El fundamento de la ingeniería de software es la capa proceso. El proceso define un marco de trabajo para un conjunto de áreas clave, las cuales forman la base del control de gestión de proyectos y establecen el contexto. Los métodos de la ingeniería de software indican cómo construir técnicamente el software. Los métodos abarcan análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Las herramientas de la ingeniería del software proporcionan un soporte automático o semi-automático para el proceso y los métodos (herramientas CASE).

El objetivo de la ingeniería de software es lograr productos de software de calidad (tanto en su forma final como durante su elaboración), mediante un proceso apoyado por métodos y herramientas. El proceso de desarrollo del software Su objetivo es la producción eficiente de un producto software que reúna los requisitos del cliente (figura 2). Este proceso es intelectual, creativo y juicio de las personas involucradas. Un proyecto de desarrollo de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, a continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción: 





Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similares. La inmadurez de la ingeniería del software como disciplina, justificada por su corta vida comparada con otras disciplinas de la ingeniería. Requisitos nuevos o modificados

Proceso de Desarrollo de Software

Sistema nuevo o modificado

Figura 2: proceso de desarrollo de software.

No existe un proceso de software universal que sea efectivo para todos los contextos de proyectos de desarrollo, es difícil automatizar todo un proceso de desarrollo de software. A pesar de la variedad de propuestas, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos: 1. 2. 3. 4.

Especificación de software: Se define la funcionalidad y restricciones operacionales que debe cumplir el software. Diseño e Implementación: Se diseña y construye el software según la especificación. Validación: El software debe validarse, debe cumplir con lo que quiere el cliente. Evolución: El software debe evolucionar, adaptarse a las necesidades del cliente.

Además de estas actividades fundamentales, Pressman menciona un conjunto de “actividades protectoras”, que se

aplican a lo largo de todo el proceso del software:    

Seguimiento y control de proyecto de software. Revisiones técnicas formales. Garantía de calidad del software. Gestión de configuración del software. Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


   

Preparación y producción de documentos. Gestión de reutilización. Mediciones. Gestión de riesgos.

Pressman caracteriza un proceso de desarrollo de software como se muestra en la Figura 3. Los elementos son: 





Un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo que son aplicables a todos los proyectos de software, con independencia del tamaño o complejidad. Un conjunto de tareas, cada uno es una colección de tareas de ingeniería del software, hitos de proyectos, entregas y productos de trabajo del software, y puntos de garantía de calidad, que permiten que las actividades del marco de trabajo se adapten a las características del proyecto de software y los requisitos del equipo del proyecto. Las actividades de protección, tales como garantía de calidad del software, gestión de configuración del software y medición, abarcan el modelo del proceso. Las actividades de protección son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Fuente: Ingeniería de software, Pressman.

Los elementos del proceso de desarrollo de software deben responder Quién debe hacer Qué, Cuándo y Cómo debe hacerlo.

Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Figura 4: Relación entre elementos del proceso del software







Quién: Las Personas participantes en el proyecto de desarrollo desempeñando uno o más Roles específicos. Qué: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando Notaciones específicas. Las Herramientas apoyan la elaboración de Artefactos soportando ciertas Notaciones. Cómo y Cuándo: Las Actividades son una serie de pasos que lleva a cabo un Rol durante el proceso de desarrollo. El avance del proyecto está controlado mediante hitos que establecen un determinado estado de terminación de ciertos Artefactos.

Fuente: Proceso de desarrollo de software, departamento de sistemas informáticos y computación, Universidad de Valencia. 1.2. ¿Qué es un Proceso? “conjunto de actividades enlazadas entre sí que, partiendo de uno o más inputs (entradas) los transforma, generando un output (resultado)”.

Para la definición de los procesos debemos considerar los siguientes elementos:

PROCESO: cualquier actividad, o serie de actividades, que transforma inputs en outputs, utilizando recursos y estando bajo ciertos controles. OUTPUTS: Los resultados de la transformación de los inputs. Los outputs es lo que reciben los clientes del proceso. Si satisfacen o superan sus necesidades, entonces se habrá logrado el resultado. Los outputs suelen ser pocos y suelen ser productos / servicios o información. Deben expresarse en formato nombre/verbo (oferta entregada al cliente, informe trimestral presentado,...).



INPUTS: son entidades que se transforman mediante procesos para convertirse en outputs. Por lo general también suelen ser productos / servicios y/o información. Los inputs los reciben las personas que llevan a cabo el proceso. Se generan fuera del proceso y pueden servir como entrada para desencadenar el proceso o ser requeridos en alguna de las etapas intermedias para poder realizar alguna actividad. CONTROLES : Definen, regulan e influyen en el proceso, aunque éste no los transforma. Los controles son internos o externos a la organización de transporte. En los controles internos se incluyen procedimientos, presupuestos, calendarios, etc. En los controles externos se incluye la legislación aplicable y el asesoramiento profesional. RECURSOS: son factores necesarios para llevar a cabo la transformación, pero que en sí no se transforman. Aquí se consideran las personas que realizan el proceso y los recursos físicos que necesitan para hacerlo (máquinas, herramientas, formación, etc.).

Figura 5: Definición de proceso según norma ISO 9001:2000

Definición de los procesos. La definición de los procesos es una de las herramientas esenciales más importantes para la mejora continua ya que:  



Se utiliza para entender y/o perfeccionar los procesos existentes y para diseñar nuevos procesos. Permite asegurarse de que los procesos están correctamente diseñados, así como detectar las carencias y necesidades de los clientes. Contribuye a definir otras influencias en el proceso y, de este modo, ayuda al equipo a entenderse con la complejidad

Fuente: http://www.fundacioncetmo.org/dgt%20mejora%20continua/pdf/Anexos/IV/IV.A.4.pdf Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Principales tipos de Procesos: Procesos Incrementales: Se busca realizar un proyecto por partes que al final del contrato terminará siendo la solución completa requerida por el cliente pero estas partes no se pueden hacer como sea, sino que dependen de lo que el cliente este necesitando con más urgencia, de los puntos mas importantes del proyecto, los requerimientos más básicos, difíciles y con mayor grado de riesgo ya que estos se deben hacer al principio, de manera que se disminuya la dificultad y el riesgo en cada versión. Se debe entregar una aplicación ejecutable (primera versión) al cliente para que este pueda trabajar en ella, y el programador pueda considerar las recomendaciones que el cliente de para hacer mejoras en el producto.

Procesos Iterativos: Son parecidos a los incrementales en lo que es la entrega de versiones pero, la diferencia es que la primera versión debe contener todos los requerimientos del usuario y lo que se va a hacer en las siguientes versiones es ir mejorando aspectos como la funcionalidad o el tiempo de respuesta. Las mejoras en cada versión pueden hacerse en un solo componente o para solucionar problemas en las versiones anteriores.

Fuente: Introducción ingeniería de software, http://esalas334.blogspot.es/1193761920/



Ciclos de vida del desarrollo de software. Hay distintos modelos de ciclo de vida que son utilizados para el desarrollo de un sistema software, algunos son mas conocidos por lo que se sabe sus virtudes y sus carencias. Cada uno es libre de utilizar cualquier tipo ya existente o incluso elaborar uno propio, ya que esto es libre y lo que se va buscando es optimizar el proceso de desarrollo conforme a los requerimientos que se nos piden en el mismo, logrando así desarrollar un programa de mayor calidad. Los factores que influyen a la hora de elegir un ciclo de vida para resolver un problema son: 1. 2. 3. 4.

Disponibilidad de recursos ya sean económicos, tiempo, equipos, humano, etc. Entender los requerimientos. Dominio del problema, si se tiene los conocimientos para dar solución al problema central. Complejidad y magnitud del proyecto.

Modelo en cascada: Implica un previo y absoluto conocimiento de los requisitos. Implica un diseño exacto y sin errores ni probable modificación o evolución ya que no permite retroceder para volver a diseñar. Cualquier cambio implica reiniciar el ciclo completo desde el principio.

Modelo en V: Es un modelo similar al modelo en cascada, pero en este caso se agrupan las actividades de análisis en la primera rama de la V y las actividades de la composición en la otra. Tiene muchos módulos que debes comprobar primero por separado y luego al juntarlos. En este modelo ves todo el conjunto no solo lo que estas haciendo.



Modelo de proceso incremental: En este modelo se entrega un primer incremento al usuario y luego se van haciendo nuevas iteraciones hasta finalizarlo. 1. Planificar los incrementos a dar al usuario. 2. Dar a cada incremento una tarea a seguir. 3. Decidir los principales bloques del programa y saber como conectarlos.

Modelo de prototipado rápido: Se realizan prototipos cuando no se logra definir lo que quiere el cliente, o el diseño que desea, así rápidamente se sabrá si se trabaja en el camino adecuado. Estos prototipos no pueden llevar mucho esfuerzo ni un gran coste ya que se van a desechar. Los prototipos serán esencialmente fachada, sin realizar las operaciones de manera correcta, incluso en un lenguaje que no sera el que se utilizará posteriormente. Se suele aplicar en métodos como el de cascada. Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Modelo de prototipado evolutivo: Similar al modelo de prototipado rápido, pero en este caso el prototipo creado no se desecha, sino que se vuelve a utilizar añadiéndole lo que le falte, volviéndole a entregar al cliente el nuevo prototipo.

Modelo en espiral: El modelo en espiral se divide en cuatro partes y se pasa por todas en cada una de las iteraciones. 1. Planificación: Economía, tiempo para realizarlo y los recursos para cada iteración. 2. Análisis de riesgos: Evaluar las posibilidades que tenemos y buscar si hay algún software parecido. Identificar posibles riesgos que puedan surgir en un futuro y preparar soluciones. 3. Ingeniería: Se abordan las tareas propias del proyecto, las actividades estructurales. Es un punto importante ya que incluye todos los pasos anteriores. 4. Evaluación: Comprobar que todo funciona correctamente y satisface al cliente.



Modelo basado en componentes: Este modelo se basa en la reutilización de partes de proyectos anteriores, sobre todo de la parte de código fuente, aunque también en diseño, análisis, etc. No tienen porque ser etapas completas, pueden ser partes de estas que las adaptamos a nuestro proyecto.



Modelos de método formal: Se basa en modelos matemáticos, sobre todo álgebra, para el análisis de requisitos. La ventaja de este modelo es que no da lugar a ambigüedad ya que utilizamos un lenguaje especifico y no un lenguaje natural. Este modelo es valido solo para software de computo no para iteración con el usuario. Suele ser muy complejo por la gran especialización de las matemáticas. 1.3.-Fases de un ciclo de proceso de desarrollo de software.

- Planificación - Análisis - Diseño - Implementación - Pruebas - Instalación o despliegue - Uso y mantenimiento

Planificación Las tareas iniciales en esta fase son:     

Delimitación del ámbito del proyecto Estudio de viabilidad Análisis de riesgos Estimación Planificación temporal y asignación de recursos

Algunos errores comunes - Abreviar las etapas iniciales del proceso de desarrollo de software (planificación y análisis, generalmente) para pasar directamente a la "construcción" del sistema. - Los errores cometidos en las fases iniciales de un proyecto son mucho más costosos de corregir a la larga, por lo que abreviar las etapas iniciales tiene graves consecuencias. - No gestionar adecuadamente los cambios que inevitablemente ocurren durante el proyecto. - Reducir la interacción con el cliente, ya que aparentemente sólo se dedica a entorpecer nuestro trabajo con sus continuos cambios de opinión y sus expectativas poco realistas. - Olvidar que añadir personal a un proyecto retrasado, por lo general, sólo lo retrasa más (la ley de Brooks). La curva de aprendizaje que se necesita para comenzar a ser productivo ha de tenerse siempre en cuenta. - Someter a los miembros de nuestro equipo a continuas interrupciones durante su jornada de trabajo (llamadas telefónicas, reuniones, consultas...). - Hacer trabajar horas extra a los miembros del equipo de desarrollo sólo sirve para disminuir su productividad (trabajo realizado por unidad de tiempo). - No informar de pequeños retrasos pensando que más tarde se recuperará el tiempo perdido. La planificación temporal del proyecto debe ir ajustándose conforme vamos aprendiendo más cosas acerca del problema al que nos enfrentamos. En el peor de los casos, se deben negociar algunos recortes con el cliente si éste desea mantener los plazos estipulados al comienzo del proyecto. Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Análisis La etapa de análisis en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer).

Un buen analista debería tener una formación adecuada en: - Técnicas de elicitación de requerimientos. - Herramientas de modelado de sistemas. - Metodologías de análisis de requerimientos. Diseño Los modelos que se utilizan en la fase de diseño representan las características del sistema que nos permitirán implementarlo de forma efectiva (el cómo). En la fase de diseño se han de estudiar posibles alternativas de implementación para el sistema de información que hemos de construir y se ha de decidir la estructura general que tendrá el sistema (su diseño arquitectónico). La solución inicial que propongamos probablemente no resulte la más adecuada para nuestro sistema de información, por lo que deberemos refinarla.

Implementación Antes de escribir una sola línea de código es fundamental haber comprendido bien el problema que se pretende resolver y haber aplicado principios básicos de diseño que nos permitan construir un sistema de información de calidad. Para la fase de implementación hemos de seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite nuestro trabajo y un lenguaje de programación apropiado para el tipo de sistema que vayamos a construir. Además de las tareas de programación asociadas a los distintos componentes de nuestro sistema, en la fase de implementación también hemos de encargarnos de la adquisición de todos los recursos necesarios para que el sistema funcione (por ejemplo, las licencias de uso del sistema gestor de bases de datos que vayamos a utilizar).

Control de versiones En todo proyecto es fundamental una adecuada gestión de la configuración del software (SCM, Software Configuration Management), más conocida vulgarmente por uno de sus aspectos, el control de versiones. De hecho, es una actividad clave en el nivel 2 del CMMI. Su valor es incalculable para evitar pérdidas irreparables (siempre y cuando se hagan copias de seguridad de la base de datos) y también para volver cómodamente a una versión anterior de nuestro código si nuestras últimas modificaciones del código no resultaron del todo acertadas.



Pruebas La etapa de pruebas tiene como objetivo detectar los errores que se hayan podido cometer en las etapas anteriores del proyecto (y, eventualmente, corregirlos), además hacerlo antes de que el usuario final del sistema los tenga que sufrir. De hecho, una prueba es un éxito cuando se detecta un error (y no al revés). Tipos de pruebas: - Las pruebas de unidad - Las pruebas de integración - Las pruebas alfa - las pruebas beta - Test de aceptación - Revisiones a todos los productos generados a lo largo del proyecto.

Instalación / Despliegue Se debe planificar el entorno en el que el sistema debe funcionar, tanto hardware como software: equipos necesarios y su configuración física, redes de interconexión entre los equipos y de acceso a sistemas externos, sistemas operativos (actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados por terceras partes, etcétera. Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintas fases, también hemos de planificar cuidadosamente la transición del sistema antiguo al nuevo de forma que sus usuarios no sufran una disrupción en el funcionamiento del sistema.

Uso y mantenimiento La etapa de mantenimiento consume típicamente del 40 al 80 por ciento de los recursos de una empresa de desarrollo de software. De hecho, con un 60% de media, es probablemente la etapa más importante del ciclo de vida del software. Dada la naturaleza del software, que ni se rompe ni se desgasta con el uso, su mantenimiento incluye tres facetas diferentes: - Eliminar los defectos que se detecten durante su vida útil (mantenimiento correctivo). - Adaptarlo a nuevas necesidades (mantenimiento adaptativo) - Añadirle nueva funcionalidad (mantenimiento perfectivo) De las distintas facetas del mantenimiento, la eliminación de defectos sólo supone el 17% del coste de mantenimiento de un sistema, mientras que el diseño e implementación de mejoras es responsable del 60% del coste de mantenimiento. Es decir, más de un tercio del coste total del software se emplea en añadirle características a software ya existente (el 60% del 60%). Se ha observado que, cuanto mejor sea el software, más tendremos que invertir en su mantenimiento, aun cuando se emplee menos esfuerzo en corregir defectos.



1.4.- Define, conceptualiza e identifica los conceptos básicos del análisis de la orientación a objeto y del paradigma de la orientación de objetos.

Análisis y Diseño Orientado a Objetos Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. El Análisis orientado a objetos ofrece un enfoque nuevo para el análisis de requisitos de sistemas software. En lugar de considerar el software desde una perspectiva clásica de entrada/proceso/salida, como los métodos estructurados clásicos, se basa en modelar el sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición) o dinámicas (uso) entre estos objetos. El uso de Análisis orientado a objetos puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software.

Características del análisis Orientado a Objetos Las técnicas orientadas a objetos se basan en organizar el software como una colección de objetos discretos que incorporan tanto estructuras de datos como comportamiento. Esto contrasta con la programación convencional, en la que las estructuras de datos y el comportamiento estaban escasamente relacionadas. Las características principales del enfoque orientado a objetos son:

Objeto. Se define a un objeto como "una entidad tangible que muestra alguna conducta bien definida". Un objeto "es cualquier cosa, real o abstracta, acerca de la cual almacenamos datos y los métodos que controlan dichos datos". Los objetos tienen una cierta "integridad" la cual no deberá ser violada. En particular, un objeto puede solamente cambiar estado, conducta, ser manipulado o estar en relación con otros objetos de manera apropiada a este objeto.

Identidad. Los datos se organizan en entidades discretas y distinguibles llamadas objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad.

Clasificación (clases). Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Una clase es una abstracción que describe propiedades (atributos y comportamiento) relevantes para una aplicación determinada, ignorando el resto. La elección de clases es arbitraria, y depende del dominio del problema.

Polimorfismo. El polimorfismo permite que una misma operación pueda llevarse a cabo de forma diferente en clases diferentes. La implementación específica de una operación determinada en una clase determinada se denomina método.

Herencia. El concepto de herencia se refiere a la compartición de atributos y operaciones basada en una relación jerárquica entre varias clases. Una clase puede definirse de forma general y luego refinarse en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y añade sus propiedades particulares.



Encapsulamiento. Hay muchos datos que no tiene porque conocerlo aquel que este usando la clase Persona; ya que son inherentes al objeto y solo controlan su funcionamiento interno; por ejemplo, cuando alguien te ve puede saber inmediatamente si eres hombre o mujer (propiedad); tambien puede conocer el color de tu cabello y ojos. En cambio, jamas sabra que cantidad de energia exacta tienes o cuantas neuronas te quedan, ni siquiera preguntandote ya que ninguna de tus propiedades externas visibles o funciones de comunicación al publico te permiten saber esos datos.

La encapsulación es muy conveniente y nos permite (Si programamos bien) colocar en funcionamiento nuestro objeto en cualquier tipo de sistema, de una manera modular y escalable (algunas de las reglas de la ingenieria del software). Abstracción. Significa extraer las propiedades esenciales de un objeto que lo distinguen de los demás tipos de Objetos y proporciona fronteras conceptuales definidas respecto al punto de vista del observador. Es la capacidad para encapsular y aislar la información de diseño y ejecución. El proceso de abstracción presenta dos aspectos complementarios. 1. Destacar los aspectos relevantes del objeto. 2. Ignorar los aspectos irrelevantes del mismo (la irrelevancia depende del nivel de abstracción, ya que si se pasa a niveles más concretos, es posible que ciertos aspectos pasen a ser relevantes).

Tipos de abstracción que podemos encontrar en un programa: 1. Abstracción funcional: crear procedimientos y funciones e invocarlos mediante un nombre donde se destaca qué hace la función y se ignora cómo lo hace. El usuario sólo necesita conocer la especificación de la abstracción (el qué) y puede ignorar el resto de los detalles (el cómo). 2. Abstracción de datos: •Tipo de datos: proporcionado por los leguajes de alto nivel. La representaci ón usada es invisible al programador, al cual solo se le permite ver las operaciones predefinidas para cada tipo. •Tipos definidos: por el programador que posibilitan la definición de valores de datos más cercanos al problema que se pretende resolver. •TDA: para la definición y representación de tipos de datos (valores + operaciones), junto con sus propiedades. •Objetos: Son TDA a los que se añade propiedades de reutilización y de compartición de código. Reutilización Una de las características más importantes de la programación orientada a objetos es la habilidad para modificar las soluciones existentes para resolver nuevos problemas. Si un tipo particular de problema ha sido resuelto utilizando la POO, un problema similar, aunque diferente, puede ser resuelto haciendo algunos cambios en el protocolo del objetomensaje ya existente.



1.5.- Define, identifica y aplica los conceptos básicos para la obtención de requerimientos funcionales y no funcionales en el proceso de desarrollo de software. Qué es el Levantamiento de Requerimientos

El Levantamiento de requerimientos se define como el proceso de identificar las necesidades del negocio, solucionando las posibles disparidades entre las personas involucradas en el mismo, con el propósito de definir y destilar los requerimientos para cumplir las restricciones impuestas por las distintas partes. Un buen proceso de levantamiento de requerimientos soporta el desarrollo de la especificación de los requerimientos, de tal forma que tengan los siguientes atributos:     

Deben ser completos, consistentes y han de estar dentro del alcance del proyecto. Deben tener un único identificador. Cumplen con los objetivos de los clientes. Son viables y apropiados para el desarrollo. Los requerimientos han de ser "testeables" (deben tener capacidad de prueba).

Requisito Funcional: característica requerida del sistema que expresa una capacidad de acción del mismo – una funcionalidad; generalmente expresada en una declaración en forma verbal. Requisito no funcional: característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo.



1.6.- Construye modelos conceptuales, aplicando el análisis orientado a objeto. El modelo conceptual se ha diseñado para: • proporcionar un marco de referencia, estructurado y claramente definido, para relacionar los datos recogidos en

los registros de autoridad con las necesidades de los usuarios de estos registros;

• ayudar en el análisis de las posibilidades de intercambio internacional y utilización de los de datos de autoridad

tanto en el sector bibliotecario como en otros sectores.

ACTIVIDADES Y DEPENDENCIAS Una de las primeras actividades centrales de un ciclo de desarrollo consiste en crear un modelo conceptual para los casos de uso del ciclo actual. Esto no puede hacerse si no se cuentan con los casos y con otros documentos que permitan identificar los conceptos (objetos). La creación no siempre es lineal; por ejemplo, el modelo conceptual puede formularse en paralelo con el desarrollo de los casos. •

•

•

Puede mostrarnos:  Conceptos  Asociaciones entre conceptos  Atributos de conceptos.



Conocimiento de la nomenclatura del dominio Los Modelos Conceptuales permiten:  Descomponer el espacio del problema en unidades comprensibles (conceptos),  Además, contribuye a esclarecer la terminología o nomenclatura del dominio. Los modelos conceptuales no son modelos de diseño de software. No corresponden al Modelo conceptual: Los artefactos del software, como una ventana o una base de datos, salvo que el dominio a modelar se refiera a  conceptos de software; por ejemplo, un modelo de interfaces gráficas para el usuario. Las responsabilidades o métodos.  Conceptos: En términos informales el concepto es una idea, cosa u objeto.

En un lenguaje más formal, podemos considerarlo a partir de su símbolo, intensión y extensión.  Símbolo: palabras o imágenes que representan un concepto.  Intensión: la definición del concepto.  Extensión: el conjunto de ejemplos a que se aplica el concepto.

Estrategias para identificar los conceptos:  Obtención de conceptos a partir de una lista de categorías de conceptos  Obtención de conceptos a partir de la identificación de frases nominales Ejemplo:

Categoría de concepto Objetos físicos o tangibles Especificaciones, diseño o descripciones cosas Lugares

Ejemplos Puesto de venta Avión de EspecificaciondeProducto Descripcionde Vuelo Tienda Aeropuerto

Transacciones

Venta, Pago Reservación

Línea o renglón de elemento de transacciones Papel de personas

VentasLineadeProducto Cajero Piloto

Contenedores de cosas

Tienda, Cesto Avión

Cosas dentro de un contenedor

Producto Pasajero

Otro sistemas de cómputos Electromecánicos SistemadeAutorizaciondeTarjetadeCredito externos al sistema ControldeTraficoAereo Otro sistemas de cómputos Electromecánicos SistemadeAutorizaciondeTarjetadeCredito externos al sistema ControldeTraficoAereo Conceptos de nombres abstractos Hambre Acrofobia Organizaciones

Departamentode VentasObj etoLineaAerea



Procesos (a menudo no están repre sentados VentaUnProduct ReservaAsiento como conceptos, pero pueden estarlo) Reglas y Políticas PoliticadeReembolso PoliticadeCancelaciones Catálogos

CatalogodeProducto Catalogodepartes

Registro de finanzas, de trabajo, de contratos de Recibo, Mayor, asuntos legales BitácoradeMantenimiento Instrumentos y servicios financieros LineadeCredito Existencia Manuales, libros

ContratodeEmpleo

ManualdePersonal ManualdeReparaciones

Ejemplo: Escenario principal El cliente llega a un puesto de venta con mercaderías y/o servicios que comprar. El cajero comienza una nueva venta. El cajero introduce el identificador del artículo. El sistema registra la línea de venta y presenta la descripción del artículo, precio y suma parcial. El cajero repite los pasos 3 y 4 hasta que se indique. El sistema presenta el total con los impuestos calculados. El cajero le dice al cliente el total y solicita el pago. Clases conceptuales candidatas para el dominio de ventas Cliente, puesto de venta, mercadería, servicio, cajero, venta, identificador de artículo, sistema, línea de venta, descripción de artículo, precio, etc. • • • •

• •

Directrices para construir modelos conceptuales Cómo construir un Modelo Conceptual:

Aplique los siguientes pasos para crear un Modelo Conceptual: Liste los conceptos idóneos usando la lista de categoría de conceptos la identificación de la frase nominal relacionadas con los requerimientos en cuestión. Dibújelos en un Modelo Conceptual o Modelo de Dominio, Incorpore las asociaciones necesarias para registrar las relaciones Agregue los atributos necesarios para cumplir con las necesidades de información •

• • •

Asignación de nombres y modelado de cosas:

El Modelo Conceptual es una especie de mapa de conceptos o cosas de un dominio: Utilice nombres existentes en el territorio Excluya las características irrelevantes No agregue cosas que no existan • • •



Errores que se cometen frecuentemente al identificar conceptos: 

Tal vez el error más frecuente cuando se crea un Modelo Conceptual es el de representar algo como atributo, cuando debió ser un concepto. Una regla práctica para no caer en él es:

Si en el mundo real no consideramos algún concepto X como número o texto, probablemente X sea un concepto y no un atribulo.

Por ejemplo: en el mundo real un aeropuerto de destino no se considera número ni texto: es una cosa masiva que ocupa espacio, por lo tanto aeropuerto debería ser un concepto. En caso de duda, convierta el atributo en un concepto independiente. Analizar aquellos conceptos semejantes con distinto nombre  Modelado de un mundo irreal 

Especificación o descripción de conceptos Incorpore una especificación o descripción de conceptos cuando: Se necesita la descripción de un artículo o servicio independiente de la existencia. La eliminación de las instancias de las cosas que describen da por resultado una pérdida de información que ha de conservarse, debido a la asociación incorrecta de la información con lo eliminado. Reduce información redundante o duplicada • •

•

1.7.- Identifica, aplica y conceptualiza las asociaciones y atributos de clases, para un análisis con orientación a objetos. Diagrama de Clase Una clase es una descripción de conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y semántica. • Las clases son gráficamente represent adas por cajas con compartimentos para:

Nombre de la clase, atributos y operaciones / métodos Responsabilidades, Reglas, Historia de Modificaciones, etc.

• Los diseñadores desarrollan clases como conjuntos de compartimentos que crecen en el tiempo agregan do

incrementalmente aspectos y funcionalidades.

Diagrama de Clases Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de agregación, ya que una clase es una descripción de conjunto de objetos que comparten los mismos atributos, operaciones, métodos, relaciones y semántica; mostrando un conjunto de elementos que son estáticos, como las clases y tipos junto con sus contenidos y relaciones.

Notación de Clase Las clases se representan por rectángulos que muestran el nombre de la clase y opcionalmente el nombre de las operaciones y atributos. Los compartimientos se usan para dividir el nombre de la clase, atributos y operaciones. Adicionalmente las restricciones, valores iniciales y parámetros se pueden asignar a clases.



Tablas Una tabla es una clase estereotipada. Esto se dibuja con un pequeño icono de la tabla en la esquina superior derecha. Los atributos de la tabla son «columnas» estereotipadas. La mayoría de las tablas tendrán una clave primaria, siendo uno o más campos los que forman una combinación única usada para acceder la tabla, más una operación de clave primaria que es «PK» estereotipada.

Atributos y Métodos Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: 





public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-,): Indica que el atributo sólo será accesible desde dentro de la Clase (sólo sus métodos lo pueden accesar). protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven.

Relaciones Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes). Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: – uno o muchos: 1..* (1..n) – 0 o muchos: 0..* (0..n) – número fijo: m (m denota el número).

Herencia Indica que una subclase hereda los métodos y atributos especificados por una superclase, de esta forma la subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la superclase.

Agregación Para modelar objetos complejos, no es suficiente con los tipos de datos básicos que proveen los lenguajes: 





Enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Asociación La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.



Dependencia o Instanciación Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación Gráfica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):

Ventajas y Desventajas Ventajas       

Genera un código automáticamente. Propone soluciones a algunos errores. Representa las relaciones entre las clases de sistema. Se diseña los componentes de los sistemas. Se protegen los datos. Se posibilita una reducción de acoplamiento. Mas fácil la comunicación entre los programadores, descubrimiento de fallas del sistema en el diseño Mejor diseño del sistema ofrece más documentación.

Desventajas 

 

Los diagramas de clases especifican qué clases hay y cómo están relacionadas, pero no cómo interactúan para alcanzar comportamientos particulares. El método tiende hacer muy lento. La instalación es muy costosa

1.8.- Define, aplica y crea diagramas de casos de uso, utilizando el análisis orientado a objetos, demostrando capacidad de abstracción. Casos de Uso (Use Case)

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso). Un diagrama de casos de uso consta de los siguientes elementos:   

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.



Elementos 

Actor :

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.



Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso. 

Relaciones: o

Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o

Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

o

Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<>) o de Herencia (<>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). Uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Ejemplo: Como ejemplo esta el caso de una Máquina Recicladora: Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:  

 



Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita: a. Describe lo depositado b. El valor de cada item c. Total El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día. El operador debe además poder cambiar: a. Información asociada a ítemes. b. Dar una alarma en el caso de que: i. Item se atora. ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:



Además podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:



A qué nivel se describen los casos de uso? No hay reglas explícitas para establecer el nivel al que se identifican los casos de uso La forma ideal de describirlos es NO describiendo el funcionamiento interno del sistema. Ejemplo: Caso de uso: Registrar Venta NO DESCRIBIRLO COMO: El sistema escribe la venta en una base de datos…. El sistema genera una sentencia SQL insert para ….



2º UNIDAD: Proceso de desarrollo orientado a objetos enfocado en Diseño orientado a objetos (DOO). Aprendizaje esperado: Construyen proyectos de software con enfoque en DOO, demostrando manejo de herramientas de asistencia computarizada a la ingeniería para el análisis y diseño OO. 2.1.- Define y conceptualiza los conceptos básicos de DOO. Diseño orientado a objetos es una etapa de la metodología orientada a objetos en lo referente al desarrollo de Software. Busca incentivar y ayudar a los programadores a pensar en términos de objetos, en vez de procedimientos cuando definen y planifican el código. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad. La ‘interfaz del objeto’ (las formas de interactuar con el objeto) también se definen en esta etapa. Un programa orientado a

objetos se caracteriza por la interacción de esos objetos. El diseño orientado a objetos es la disciplina que define los objetos y sus interacciones para resolver un problema de negocio que fue identificado y documentado durante el análisis orientado a objetos. Fuente: Fundamentos del diseño de software, unidad 4 diseño orientado a objeto, http://cufmingsoftware.wordpress.com/diseno-orientado-a-objeto/ Etapas del diseño orientado a objetos.

1. Planificación y Especificación de Requisitos: Planificación, definición de requisitos, conocer los procesos del dominio, etc. 2. Construcción: La construcción del sistema. Se subdivide en las siguientes: 



 

Análisis: analizar el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. Diseño: Se especifica el diseño en detalle, describiendo cómo funcionará internamente para satisfacer lo especificado en el análisis. Implementación: Se lleva lo especificado en el diseño a un lenguaje de programación. Pruebas: Se realizan una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos.

3. Instalación: La puesta en marcha del sistema en el entorno previsto. Fuente: Universidad de Alcalá, http://www.cc.uah.es/jlcastillo/POO/POO_07.htm 2.2.- Identifica y aplica los aspectos básicos y necesarios en e l diseño de sistemas con orientación a objetos.

Principios del diseño orientado a objetos: Responsabilidad Única: Cada clase debe ser responsable de realizar solo una actividad del sistema Clase Abierta y Cerrada: Una clase debe ser abierta a la extensión y cerrada a la modificación Principio de Substitución de Liskov: Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas Principio de Inversión de Dependencia: Los módulos de nivel superior no deben depender sino de las abstracciones. Los detalles deben depender a su vez de las abstracciones, no al contrario Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Principio de Segregación de Interfaces: La implementación de las abstracciones (que contradictorio) debe estar en la medida de lo posible en interfaces y no en clases Nota: estos 5 primeros principios no se deben olvidar mientras se utilicen las clases. Principio de Equivalencia de Reuso y Distribución : Solo los componentes que se distribuyen de manera final pueden ser reutilizados, el elemento mas importante es entonces el paquete. Principio de Cierre Común: Los componentes que comparten funciones entre ellos o que dependen uno del otro deberían ser colocados juntos Principio de Reuso Común: Si se reutiliza una clase de un paquete entonces se reutilizan todas Principio de Dependencias acíclicas: Los paquetes y sus dependencias no deben formar ciclos entre sí. Principio de Dependencias Estables: Los paquetes menos estables han de depender de los paquetes más estables Principio de Abstracción Estable: Los paquetes deben ser más abstractos mientras mas estables son Ventajas de las Técnicas Orientada a Objetos

Reutilización Estabilidad Comportamiento de objetos Construcción de clases más complejas Confiabilidad Nuevos mercados de software Rápido diseño Mayor calidad de diseño Integridad Programación más sencilla Mantenimiento más sencillo

Desventajas de las Técnicas Orientada a Objetos

Alta curva de aprendizaje Costosa Requiere conocimientos adicionales No recomendable para proyectos pequeños Requiere personal especializado

2.3.- Define, conceptualiza y aplica el concepto de arquitectura sobre el diseño con orientación a objetos.

Arquitectura de 3 niveles Busca ayudar a construir componentes físicos a partir de los niveles lógicos. Se toman decisiones sobre qué parte lógica de la aplicación se va a encapsular en cada uno de los componentes de igual modo que se encapsulan los componentes en varios niveles. Un nivel está conformado por varios componentes, por tanto puede suplir varios servicios.



Nivel de Usuario Los componentes del nivel de usuario, proporcionan la interfaz visual que los clientes utilizarán para ver la información y los datos. En este nivel, los componentes son responsables de solicitar y recibir servicios de otros componentes del mismo nivel o del nivel de servicios de negocio. La forma de operar del sistema es transparente para el usuario. •

Nivel de Negocios Los servicios de usuario no pueden contactar directamente con el nivel de servicios de datos, es responsabilidad de los servicios de negocio hacer de puente entre estos. Los componentes de los servicios de negocio evitan que el usuario tenga acceso directo a la base de datos, lo cual proporciona mayor seguridad en la integridad de ésta. •

Nivel de Datos El nivel de datos se encarga de las típicas tareas con los datos: Inserción, modificación, consulta y borrado. Un nivel de servicios de datos apropiadamente implementado, debería permitir cambiar su localización sin afectar a los servicios proporcionados por los componentes de negocio. •

Ventajas Los componentes de la aplicación pueden ser desarrollados en cualquier lenguaje. Los componentes son independientes. Los componentes pueden estar distribuidos en múltiples servidores. La D.B. es solo vista desde la capa intermedia y no desde todos los clientes. Los drivers del D.B. No tienen que estar en los clientes. Mejora la administración de los recursos cuando existe mucha concurrencia. Permite reutilización real del software y construir aplicaciones escalables. • • • • • • •

Paquetes Ver el primer proyecto y darse cuenta que por ejemplo tiene tantos diagramas que se ha hace imposible entender las ideas macro del mismo es una situación mas común de lo que uno cree, incluso se puede llevar esta situación a la vida misma. Solo se debe utilizar una filosofía antigua :”divide y vencerás”. Lo que se debe hacer es dividir un modelo (líneas de código, de casos de uso, clases, etc.) en varias partes agrupando elementos que tengan algún tipo de coincidencia entre sí. Así como en un computador se organizan documentos en “carpetas”, se pueden organizar casos de uso, clases,

componentes, actores y todo tipo de elementos en los paquetes de UML.

2.4.- Define, aplica y crea diagramas de casos de uso explotados utilizando el análisis orientado a objetos, demostrando capacidad de abstracción.

Creación de casos de uso Crear casos de uso es una verdadera ciencia. No existen reglas absolutas. La idea es comunicar información de manera clara, precisa y detallada, que sea entendible para cualquier tipo de audiencia para poder tener proyectos exitosos.

Un caso de uso es una lista de pasos que especifican como un usuario interactúa con el negocio o sistema, teniendo en cuenta el valor que esta interacción le da al usuario o a otros grupos de interés. Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproducción. Derechos reservados AIEP.


Un Caso de uso es la historia de cómo un negocio o un sistema interactúa con el usuario Fuente: Consejos para escribir buenos casos de uso, TIS 2009 Consejos para los casos de uso. Los casos de uso se representan mediante óvalos y también como especificaciones textuales, pues bien el texto es la esencia del modelo de casos de uso, pero diagramar ayuda mucho mas a comunicar los requerimientos al alto nivel y lo que esta dentro y fuera del alcance. Los actores humanos deben ser el elemento más importante, ya que el actor humano representa las relaciones e interacciones mas interesantes y difíciles para los sistemas. Ser estructurado para crear casos de uso, crear una larga lista de pasos de principio a fin. Un caso de uso debería tener un único flujo principal y múltiples flujos alternativos. Ser cuidadoso con la sentencia “if”, ya que utilizarla más de una vez en un flujo significa que se están especificando múltiples requerimientos, es poco legible. Se debe romper cada “if” en su propio flujo.

2.5.- Define, aplica y crea diagramas de colaboración utilizando el análisis orientado a objetos, demostrando capacidad de abstracción. Diagrama de colaboración: es una forma de representar interacción entre objetos.   

Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. Consiste especificar un contrato entre objetos Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace".

Un Diagrama de Colaboración muestra una interacción ordenada y organizada basándose en los objetos que interactúan y los enlaces entre ellos.

UML –Interacciones  Los objetos interactúan entre sí enviándose mensajes.  Los objetos se conectan a través de enlaces. Mensaje: específica transmisión de información entre objetos. Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.  Es una conexión semántica entre objetos.  Es una instancia de una relación.  Puede contener los adornos de la relación. Elementos de un diagrama de colaboración.    

Objetos o Roles: nodos del grafo. Enlaces o comunicaciones: arcos del grafo. Mensajes: llevan número de secuencia y flecha dirigida. Anidamiento: se utiliza la numeración decimal Ej.: 1, 1.1, 1.1.1.....







Iteración: colocar un * antes del número de secuencia y una cláusula de condición, si es necesario. ej. *[x>0]. Bifurcación: los caminos alternativos tendrán el mismo número de secuencia, seguido del número de subsecuencia, y se deben distinguir por una condición.

Ejemplo: Un lector solicita un libro al bibliotecario, y le brinda su título. El bibliotecario busca el libro en un índice y solicita al asistente que le alcance el libro. Diagrama de secuencia

Fuente: Diagrama de colaboración, virtual.usalesiana.edu.bo/web/practica/archiv/colabora2.ppt



2.6.- Define, aplica y crea diagramas de secuencia utilizando el análisis orientado a objetos, demostrando capacidad de abstracción.

Diagrama de secuencia: indica módulos o clases que son parte del programa y las llamadas que se hacen en cada uno de ellos para realizar una tarea determinada. Se realizan para definir acciones que se pueden realizar en una aplicación. En el caso de una aplicación para jugar al ajedrez, se podrían realizar diagramas de secuencia para “jugar una par tida” o bien para acciones más específicas como “mover pieza”.

El detalle que se muestre en el diagrama de secuencia debe ser acorde con lo que se desea mostrar o bien con la fase de desarrollo en la que se encuentra el proyecto. El detalle del diagrama depende de la fase en la que estemos, lo que pretendamos contar con el diagrama y a quién. En el diagrama de secuencia no se ponen situaciones erróneas (poner todos los detalles crea un diagrama muchas veces imposible de entender). El diagrama puede acompañarse con un texto en el que se detallen todas estas situaciones erróneas y particularidades. Fuente: Diagrama de secuencia, Jesús Caceres Tello, depto. ciencias de la computación, Universidad de Alcalá. 2.7.- Diseña un sistema sencillo utilizando los recursos de la orientación a objetos, utilizando herramientas de asistencia computarizada a la ingeniería. 2.8.- Crea un proceso de desarrollo de software, aplicando los conceptos de la orientación a objetos. Proceso de desarrollo de software Define el qué, quién, cuándo y cómo del desarrollo de software. Cuatro actividades fundamentales que son comunes para todos los procesos de desarrollo de software: Especificación del software Desarrollo del software Validación del software Evolución del software    

Dividir un proyecto en mini-proyectos, más fáciles de manejar y completar. Cada mini-proyecto es una iteración. Cada iteración contiene todos los elementos de un proyecto normal: • Planificación • Análisis y diseño • Construcción • Integración y pruebas • Versión del producto (interna o externa) Cada iteración genera una línea base (baseline) que comprende una versión parcialmente completa del sistema final, y toda la documentación asociada. Las sucesivas iteraciones se construyen unas sobre otras hasta que se alcanza el sistema final terminado Fuente: Proceso de desarrollo de software, Universidad Carlos III de Madrid.


Taller de Herramientas de Productividad

Recommend Documents