Taller de Herramientas de Productividad

Vicerrectora Acadmica
Cuaderno de Apuntes 2013

Cuaderno de Apuntes de uso exclusivo de los estudiantes del Instituto Profesional AIEP. Prohibida su reproduccin. 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 Mdulo que cursas, encontrars Conceptos, Ideas Centrales y Aplicaciones que reforzarn el
aprendizaje que debes lograr.

Esperamos que estas Ideas Claves entregadas a modo de sntesis te orienten en el desarrollo del saber, del hacer y del
ser.

Mucho xito.-

Direccin de Desarrollo Curricular y Evaluacin
VICERRECTORA ACADMICA AIEP



Mdulo: TALLER DE HERRAMIENTAS DE PRODUCTIVIDAD

UNIDAD 1 : Proceso de desarrollo orientado a objetos enfocado en el anlisis orientado a objetos (ADO)

Aprendizaje Esperado: Aplicar el proceso de desarrollo de software a travs de las herramientas esenciales para el
proceso de software y fases de un ciclo de vida, con anlisis orientado a objetos.
El anlisis y diseo orientado a objetos (ADO) es un enfoque de la ingeniera de software que modela un sistema como un
grupo de objetos que interactan entre s. Las metodologas de anlisis y diseo ms modernas son casos de uso guiados
a travs de requerimientos, diseo, implementacin, pruebas, y despliegue.

1.1 Proceso de desarrollo de software.

Un sistema informtico se compone de HW y SW. En relacion al HW, su produccin se realiza sistemticamente y la base
de conocimiento para el desarrollo se define claramente. Respecto al SW, su construccin 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 difciles de prever y normalmente superan las estimaciones.
La modificacin del software es una tarea difcil 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 tarda validacin con el cliente.
Inadecuada gestin de los requisitos.
No existe medicin del proceso ni registro de datos histricos.
Estimaciones imprevistas de plazos y costos.
Excesiva e irracional presin en los plazos.
Escaso o deficiente control en el progreso del proceso de desarrollo.
No se hace gestin de riesgos formalmente.
No se realiza un proceso formal de pruebas.
No se realizan revisiones tcnicas formales e inspecciones de cdigo.

Ingeniera del software:
La aplicacin de un enfoque sistemtico, disciplinado y cuantificable para el desarrollo, operacin y
mantenimiento del software.

El libro Ingenieria de Software de Pressman define la Ingeniera de Software como una tecnologa multicapa, como
aparece en la Figura 1.

Figura 1: Capas de la Ingeniera de Software.


Cualquier disciplina de ingeniera debe estar sustentada sobre la calidad. Gestionar con calidad permite tener una
cultura de mejoras de procesos.
El fundamento de la ingeniera 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 gestin de proyectos y establecen el contexto.
Los mtodos de la ingeniera de software indican cmo construir tcnicamente el software. Los mtodos abarcan
anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento.
Las herramientas de la ingeniera del software proporcionan un soporte automtico o semi-automtico para el proceso
y los mtodos (herramientas CASE).

El objetivo de la ingeniera de software es lograr productos de software de calidad (tanto en su forma final como
durante su elaboracin), mediante un proceso apoyado por mtodos y herramientas.

El proceso de desarrollo del software
Su objetivo es la produccin eficiente de un producto software que rena 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 ingeniera, a continuacin se explican algunas particularidades asociadas al
desarrollo de software y que influyen en su proceso de construccin:

Un producto software en s es complejo, es prcticamente inviable conseguir un 100% de confiabilidad de un
programa por pequeo que sea.
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definicin del producto y sus
requisitos, sobre todo cuando no se tiene precedentes en productos software similares.
La inmadurez de la ingeniera del software como disciplina, justificada por su corta vida comparada con otras
disciplinas de la ingeniera.

Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software
Requisitos nuevos
o modificados
Sistema nuevo
o modificado
Proceso de Desarrollo
de Software

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 difcil
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. Especificacin de software: Se define la funcionalidad y restricciones operacionales que debe cumplir el software.
2. Diseo e Implementacin: Se disea y construye el software segn la especificacin.
3. Validacin: El software debe validarse, debe cumplir con lo que quiere el cliente.
4. Evolucin: El software debe evolucionar, adaptarse a las necesidades del cliente.

Adems 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 tcnicas formales.
Garanta de calidad del software.
Gestin de configuracin del software.

Preparacin y produccin de documentos.
Gestin de reutilizacin.
Mediciones.
Gestin de riesgos.

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

Un marco comn del proceso, definiendo un pequeo nmero de actividades del marco de trabajo que son
aplicables a todos los proyectos de software, con independencia del tamao o complejidad.

Un conjunto de tareas, cada uno es una coleccin de tareas de ingeniera del software, hitos de proyectos, entregas y
productos de trabajo del software, y puntos de garanta de calidad, que permiten que las actividades del marco de
trabajo se adapten a las caractersticas del proyecto de software y los requisitos del equipo del proyecto.

Las actividades de proteccin, tales como garanta de calidad del software, gestin de configuracin del software y
medicin, abarcan el modelo del proceso. Las actividades de proteccin son independientes de cualquier actividad del
marco de trabajo y aparecen durante todo el proceso.

Figura 3: Elementos del proceso del software

Fuente: Ingeniera de software, Pressman.

Los elementos del proceso de desarrollo de software deben responder Quin debe hacer Qu, Cundo y Cmo
debe hacerlo.



Figura 4: Relacin entre elementos del proceso del software

Quin: Las Personas participantes en el proyecto de desarrollo desempeando uno o ms Roles especficos.

Qu: Un Artefacto es producido por un Rol en una de sus Actividades. Los Artefactos se especifican utilizando
Notaciones especficas. Las Herramientas apoyan la elaboracin de Artefactos soportando ciertas Notaciones.

Cmo y Cundo: 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 terminacin de ciertos
Artefactos.

Fuente: Proceso de desarrollo de software, departamento de sistemas informticos y computacin, Universidad de
Valencia.

1.2. Qu es un Proceso?
conjunto de actividades enlazadas entre s que, partiendo de uno o ms inputs (entradas) los transforma,
generando un output (resultado).

Para la definicin 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 transformacin 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 informacin. 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 tambin suelen
ser productos / servicios y/o informacin. 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 organizacin de transporte. En los controles internos se incluyen procedimientos, presupuestos, calendarios,
etc. En los controles externos se incluye la legislacin aplicable y el asesoramiento profesional.

RECURSOS: son factores necesarios para llevar a cabo la transformacin, pero que en s no se transforman. Aqu se
consideran las personas que realizan el proceso y los recursos fsicos que necesitan para hacerlo (mquinas,
herramientas, formacin, etc.).

Figura 5: Definicin de proceso segn norma ISO 9001:2000

Definicin de los procesos.

La definicin de los procesos es una de las herramientas esenciales ms importantes para la mejora continua ya que:

Se utiliza para entender y/o perfeccionar los procesos existentes y para disear nuevos procesos.
Permite asegurarse de que los procesos estn correctamente diseados, 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



Principales tipos de Procesos:

Procesos Incrementales:

Se busca realizar un proyecto por partes que al final del contrato terminar siendo la solucin 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 ms
urgencia, de los puntos mas importantes del proyecto, los requerimientos ms bsicos, difciles 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 versin. Se
debe entregar una aplicacin ejecutable (primera versin) 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 versin 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 versin pueden hacerse en un solo componente o para solucionar problemas en las versiones
anteriores.

Fuente: Introduccin ingeniera 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. Disponibilidad de recursos ya sean econmicos, tiempo, equipos, humano, etc.
2. Entender los requerimientos.
3. Dominio del problema, si se tiene los conocimientos para dar solucin al problema central.
4. Complejidad y magnitud del proyecto.

Modelo en cascada:

Implica un previo y absoluto conocimiento de los requisitos. Implica un diseo exacto y sin errores ni probable modificacin
o evolucin ya que no permite retroceder para volver a disear. 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 anlisis en la primera rama
de la V y las actividades de la composicin en la otra. Tiene muchos mdulos 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 rpido:

Se realizan prototipos cuando no se logra definir lo que quiere el cliente, o el diseo que desea, as rpidamente 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 sern 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 mtodos como el de cascada.



Modelo de prototipado evolutivo:

Similar al modelo de prototipado rpido, pero en este caso el prototipo creado no se desecha, sino que se vuelve a utilizar
aadindole lo que le falte, volvindole 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. Planificacin: Economa, tiempo para realizarlo y los recursos para cada iteracin.
2. Anlisis de riesgos: Evaluar las posibilidades que tenemos y buscar si hay algn software parecido. Identificar
posibles riesgos que puedan surgir en un futuro y preparar soluciones.
3. Ingeniera: Se abordan las tareas propias del proyecto, las actividades estructurales. Es un punto importante ya
que incluye todos los pasos anteriores.
4. Evaluacin: Comprobar que todo funciona correctamente y satisface al cliente.



Modelo basado en componentes:

Este modelo se basa en la reutilizacin de partes de proyectos anteriores, sobre todo de la parte de cdigo fuente, aunque
tambin en diseo, anlisis, etc. No tienen porque ser etapas completas, pueden ser partes de estas que las adaptamos a
nuestro proyecto.


Modelos de mtodo formal:

Se basa en modelos matemticos, sobre todo lgebra, para el anlisis de requisitos. La ventaja de este modelo es que no
da lugar a ambigedad ya que utilizamos un lenguaje especifico y no un lenguaje natural. Este modelo es valido solo para
software de computo no para iteracin con el usuario. Suele ser muy complejo por la gran especializacin de las
matemticas.

1.3.-Fases de un ciclo de proceso de desarrollo de software.

- Planificacin
- Anlisis
- Diseo
- Implementacin
- Pruebas
- Instalacin o despliegue
- Uso y mantenimiento

Planificacin

Las tareas iniciales en esta fase son:

Delimitacin del mbito del proyecto
Estudio de viabilidad
Anlisis de riesgos
Estimacin
Planificacin temporal y asignacin de recursos

Algunos errores comunes

- Abreviar las etapas iniciales del proceso de desarrollo de software (planificacin y anlisis, generalmente) para pasar
directamente a la "construccin" del sistema.
- Los errores cometidos en las fases iniciales de un proyecto son mucho ms 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 interaccin con el cliente, ya que aparentemente slo se dedica a entorpecer nuestro trabajo con sus
continuos cambios de opinin y sus expectativas poco realistas.
- Olvidar que aadir personal a un proyecto retrasado, por lo general, slo lo retrasa ms (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
telefnicas, reuniones, consultas...).
- Hacer trabajar horas extra a los miembros del equipo de desarrollo slo sirve para disminuir su productividad (trabajo
realizado por unidad de tiempo).
- No informar de pequeos retrasos pensando que ms tarde se recuperar el tiempo perdido. La planificacin temporal
del proyecto debe ir ajustndose conforme vamos aprendiendo ms 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.

Anlisis

La etapa de anlisis 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 comprensin adecuada de los requerimientos del sistema (las caractersticas
que el sistema debe poseer).

Un buen analista debera tener una formacin adecuada en:
- Tcnicas de elicitacin de requerimientos.
- Herramientas de modelado de sistemas.
- Metodologas de anlisis de requerimientos.

Diseo

Los modelos que se utilizan en la fase de diseo representan las caractersticas del sistema que nos permitirn
implementarlo de forma efectiva (el cmo).
En la fase de diseo se han de estudiar posibles alternativas de implementacin para el sistema de informacin que
hemos de construir y se ha de decidir la estructura general que tendr el sistema (su diseo arquitectnico). La solucin
inicial que propongamos probablemente no resulte la ms adecuada para nuestro sistema de informacin, por lo que
deberemos refinarla.

Implementacin

Antes de escribir una sola lnea de cdigo es fundamental haber comprendido bien el problema que se pretende resolver y
haber aplicado principios bsicos de diseo que nos permitan construir un sistema de informacin de calidad.
Para la fase de implementacin hemos de seleccionar las herramientas adecuadas, un entorno de desarrollo que facilite
nuestro trabajo y un lenguaje de programacin apropiado para el tipo de sistema que vayamos a construir. Adems de las
tareas de programacin asociadas a los distintos componentes de nuestro sistema, en la fase de implementacin tambin
hemos de encargarnos de la adquisicin 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 gestin de la configuracin del software (SCM, Software Configuration
Management), ms 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 prdidas irreparables (siempre y cuando se hagan copias de seguridad de la base de
datos) y tambin para volver cmodamente a una versin anterior de nuestro cdigo si nuestras ltimas modificaciones del
cdigo 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), adems 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 revs).
Tipos de pruebas:
- Las pruebas de unidad
- Las pruebas de integracin
- Las pruebas alfa
- las pruebas beta
- Test de aceptacin
- Revisiones a todos los productos generados a lo largo del proyecto.

Instalacin / Despliegue

Se debe planificar el entorno en el que el sistema debe funcionar, tanto hardware como software: equipos necesarios y su
configuracin fsica, redes de interconexin entre los equipos y de acceso a sistemas externos, sistemas operativos
(actualizados para evitar problemas de seguridad), bibliotecas y componentes suministrados por terceras partes, etctera.
Si nuestro sistema reemplaza a un sistema anterior o se despliega paulatinamente en distintas fases, tambin hemos de
planificar cuidadosamente la transicin del sistema antiguo al nuevo de forma que sus usuarios no sufran una disrupcin
en el funcionamiento del sistema.

Uso y mantenimiento

La etapa de mantenimiento consume tpicamente 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 ms 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)
- Aadirle nueva funcionalidad (mantenimiento perfectivo)
De las distintas facetas del mantenimiento, la eliminacin de defectos slo supone el 17% del coste de mantenimiento de
un sistema, mientras que el diseo e implementacin de mejoras es responsable del 60% del coste de mantenimiento. Es
decir, ms de un tercio del coste total del software se emplea en aadirle caractersticas a software ya existente (el 60%
del 60%).
Se ha observado que, cuanto mejor sea el software, ms tendremos que invertir en su mantenimiento, aun cuando se
emplee menos esfuerzo en corregir defectos.


1.4.- Define, conceptualiza e identifica los conceptos bsicos del anlisis de la orientacin a objeto y del paradigma de la
orientacin de objetos.

Anlisis y Diseo Orientado a Objetos

Es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio del problema.
El Anlisis orientado a objetos ofrece un enfoque nuevo para el anlisis de requisitos de sistemas software. En lugar de
considerar el software desde una perspectiva clsica de entrada/proceso/salida, como los mtodos estructurados clsicos,
se basa en modelar el sistema mediante los objetos que forman parte de l y las relaciones estticas (herencia y
composicin) o dinmicas (uso) entre estos objetos.
El uso de Anlisis orientado a objetos puede facilitar mucho la creacin de prototipos, y las tcnicas de desarrollo evolutivo
de software.

Caractersticas del anlisis Orientado a Objetos

Las tcnicas orientadas a objetos se basan en organizar el software como una coleccin de objetos discretos que
incorporan tanto estructuras de datos como comportamiento. Esto contrasta con la programacin convencional, en la que
las estructuras de datos y el comportamiento estaban escasamente relacionadas.
Las caractersticas 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 mtodos 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 relacin 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.

Clasificacin (clases).

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

Polimorfismo.

El polimorfismo permite que una misma operacin pueda llevarse a cabo de forma diferente en clases diferentes. La
implementacin especfica de una operacin determinada en una clase determinada se denomina mtodo.

Herencia.

El concepto de herencia se refiere a la comparticin de atributos y operaciones basada en una relacin jerrquica 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 aade 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 comunicacin al publico te permiten saber esos datos.

La encapsulacin 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).

Abstraccin.

Significa extraer las propiedades esenciales de un objeto que lo distinguen de los dems tipos de Objetos y proporciona
fronteras conceptuales definidas respecto al punto de vista del observador. Es la capacidad para encapsular y aislar la
informacin de diseo y ejecucin.
El proceso de abstraccin presenta dos aspectos complementarios.
1. Destacar los aspectos relevantes del objeto.
2. Ignorar los aspectos irrelevantes del mismo (la irrelevancia depende del nivel de abstraccin, ya que si se pasa a
niveles ms concretos, es posible que ciertos aspectos pasen a ser relevantes).

Tipos de abstraccin que podemos encontrar en un programa:
1. Abstraccin funcional: crear procedimientos y funciones e invocarlos mediante un nombre donde se destaca qu hace la
funcin y se ignora cmo lo hace. El usuario slo necesita conocer la especificacin de la abstraccin (el qu) y puede
ignorar el resto de los detalles (el cmo).
2. Abstraccin de datos:
Tipo de datos: proporcionado por los leguajes de alto nivel. La representacin 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 definicin de valores de datos ms cercanos al problema que se
pretende resolver.
TDA: para la definicin y representacin de tipos de datos (valores + operaciones), junto con sus propiedades.
Objetos: Son TDA a los que se aade propiedades de reutilizacin y de comparticin de cdigo.

Reutilizacin

Una de las caractersticas ms importantes de la programacin 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 objeto-
mensaje ya existente.


1.5.- Define, identifica y aplica los conceptos bsicos para la obtencin 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 propsito 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 especificacin 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: caracterstica requerida del sistema que expresa una capacidad de accin del mismo una
funcionalidad; generalmente expresada en una declaracin en forma verbal.
Requisito no funcional: caracterstica requerida del sistema, del proceso de desarrollo, del servicio prestado o de
cualquier otro aspecto del desarrollo, que seala una restriccin del mismo.


1.6.- Construye modelos conceptuales, aplicando el anlisis orientado a objeto.

El modelo conceptual se ha diseado 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 anlisis de las posibilidades de intercambio internacional y utilizacin 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 creacin 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),
Adems, contribuye a esclarecer la terminologa o nomenclatura del dominio.

Los modelos conceptuales no son modelos de diseo 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 grficas para el usuario.
Las responsabilidades o mtodos.

Conceptos:
En trminos informales el concepto es una idea, cosa u objeto.
En un lenguaje ms formal, podemos considerarlo a partir de su smbolo, intensin y extensin.
Smbolo: palabras o imgenes que representan un concepto.
Intensin: la definicin del concepto.
Extensin: el conjunto de ejemplos a que se aplica el concepto.

Estrategias para identificar los conceptos:
Obtencin de conceptos a partir de una lista de categoras de conceptos
Obtencin de conceptos a partir de la identificacin de frases nominales

Ejemplo:

Categora de concepto Ejemplos
Objetos fsicos o tangibles Puesto de venta Avin
Especificaciones, diseo o descripciones de
cosas
EspecificaciondeProducto Descripcionde Vuelo
Lugares Tienda Aeropuerto
Transacciones Venta, Pago Reservacin
Lnea o rengln de elemento de transacciones VentasLineadeProducto
Papel de personas Cajero Piloto
Contenedores de cosas Tienda, Cesto Avin
Cosas dentro de un contenedor Producto Pasajero
Otro sistemas de cmputos Electromecnicos
externos al sistema
SistemadeAutorizaciondeTarjetadeCredito
ControldeTraficoAereo
Otro sistemas de cmputos Electromecnicos
externos al sistema
SistemadeAutorizaciondeTarjetadeCredito
ControldeTraficoAereo
Conceptos de nombres abstractos Hambre Acrofobia
Organizaciones Departamentode VentasObj etoLineaAerea

Procesos (a menudo no estn repre sentados
como conceptos, pero pueden estarlo)
VentaUnProduct ReservaAsiento
Reglas y Polticas PoliticadeReembolso PoliticadeCancelaciones
Catlogos CatalogodeProducto Catalogodepartes
Registro de finanzas, de trabajo, de contratos de
asuntos legales
Recibo, Mayor, ContratodeEmpleo
BitcoradeMantenimiento
Instrumentos y servicios financieros LineadeCredito Existencia
Manuales, libros ManualdePersonal ManualdeReparaciones

Ejemplo:
Escenario principal
El cliente llega a un puesto de venta con mercaderas y/o servicios que comprar.
El cajero comienza una nueva venta.
El cajero introduce el identificador del artculo.
El sistema registra la lnea de venta y presenta la descripcin del artculo, 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, mercadera, servicio, cajero, venta, identificador de artculo, sistema, lnea de venta, descripcin
de artculo, precio, etc.

Directrices para construir modelos conceptuales

Cmo construir un Modelo Conceptual:

Aplique los siguientes pasos para crear un Modelo Conceptual:
Liste los conceptos idneos usando la lista de categora de conceptos la identificacin de la frase nominal
relacionadas con los requerimientos en cuestin.
Dibjelos 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 informacin

Asignacin 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 caractersticas irrelevantes
No agregue cosas que no existan


Errores que se cometen frecuentemente al identificar conceptos:

Tal vez el error ms frecuente cuando se crea un Modelo Conceptual es el de representar algo como atributo,
cuando debi ser un concepto.
Una regla prctica para no caer en l es:
Si en el mundo real no consideramos algn concepto X como nmero o texto, probablemente X sea un concepto y no un
atribulo.
Por ejemplo: en el mundo real un aeropuerto de destino no se considera nmero ni texto: es una cosa masiva que
ocupa espacio, por lo tanto aeropuerto debera 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

Especificacin o descripcin de conceptos

Incorpore una especificacin o descripcin de conceptos cuando:
Se necesita la descripcin de un artculo o servicio independiente de la existencia.
La eliminacin de las instancias de las cosas que describen da por resultado una prdida de informacin que ha
de conservarse, debido a la asociacin incorrecta de la informacin con lo eliminado.
Reduce informacin redundante o duplicada

1.7.- Identifica, aplica y conceptualiza las asociaciones y atributos de clases, para un anlisis con orientacin a objetos.

Diagrama de Clase
Una clase es una descripcin de conjunto de objetos que comparten los mismos atributos, operaciones, mtodos,
relaciones y semntica.

Las clases son grficamente representadas por cajas con compartimentos para:
Nombre de la clase, atributos y operaciones / mtodos
Responsabilidades, Reglas, Historia de Modificaciones, etc.

Los diseadores desarrollan clases como conjuntos de compartimentos que crecen en el tiempo agregando
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 agregacin, ya que una clase es una descripcin de conjunto de objetos que
comparten los mismos atributos, operaciones, mtodos, relaciones y semntica; mostrando un conjunto de elementos que
son estticos, como las clases y tipos junto con sus contenidos y relaciones.
Notacin de Clase
Las clases se representan por rectngulos 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 parmetros se pueden asignar a clases.


Tablas
Una tabla es una clase estereotipada. Esto se dibuja con un pequeo icono de la tabla en la esquina superior derecha. Los
atributos de la tabla son columnas estereotipadas. La mayora de las tablas tendrn una clave primaria, siendo uno o
ms campos los que forman una combinacin nica usada para acceder la tabla, ms una operacin de clave primaria que
es PK estereotipada.
Atributos y Mtodos
Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el grado de comunicacin 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 slo ser accesible desde dentro de la Clase (slo sus mtodos lo pueden
accesar).
protected (#,): Indica que el atributo no ser accesible desde fuera de la clase, pero si podr ser accesado por
mtodos de la clase adems de las subclases que se deriven.
Relaciones
Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o ms clases (cada uno
con caractersticas 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 relacin y stas
pueden ser: uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) nmero fijo: m (m denota el nmero).
Herencia
Indica que una subclase hereda los mtodos y atributos especificados por una superclase, de esta forma la subclase
adems de poseer sus propios mtodos y atributos, poseer las caractersticas y atributos visibles de la superclase.
Agregacin
Para modelar objetos complejos, no es suficiente con los tipos de datos bsicos 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 aplicacin, tenemos dos posibilidades:
Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto incluido esta condicionado por el
tiempo de vida del que lo incluye. Este tipo de relacin es comnmente llamada Composicin (el Objeto base se
construye a partir del objeto incluido, es decir, es "parte/todo").
Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto incluido es independiente
del que lo incluye. Este tipo de relacin es comnmente llamada Agregacin (el objeto base utiliza al incluido para
su funcionamiento).
Asociacin
La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran entre si. Cabe destacar que no
es una relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.


Dependencia o Instanciacin
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su instanciacin es dependiente de otro
objeto/clase). Se denota por una flecha punteada. El uso ms particular de este tipo de relacin es para denotar la
dependencia que tiene una clase de otra, como por ejemplo una aplicacin Grfica que instancia una ventana (la creacin
del Objeto Ventana esta condicionado a la instanciacin proveniente desde el objeto Aplicacin):
Ventajas y Desventajas
Ventajas
Genera un cdigo automticamente.
Propone soluciones a algunos errores.
Representa las relaciones entre las clases de sistema.
Se disea los componentes de los sistemas.
Se protegen los datos.
Se posibilita una reduccin de acoplamiento.
Mas fcil la comunicacin entre los programadores, descubrimiento de fallas del sistema en el diseo Mejor
diseo del sistema ofrece ms documentacin.
Desventajas
Los diagramas de clases especifican qu clases hay y cmo estn relacionadas, pero no cmo interactan para
alcanzar comportamientos particulares.
El mtodo tiende hacer muy lento.
La instalacin es muy costosa

1.8.- Define, aplica y crea diagramas de casos de uso, utilizando el anlisis orientado a objetos, demostrando capacidad
de abstraccin.

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,
adems 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 Comunicacin.


Elementos
Actor:

Una definicin 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 ms bien la labor que realiza frente al sistema.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente externo, sea desde una peticin
de un actor o bien desde la invocacin desde otro caso de uso.
Relaciones:
o Asociacin
Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso de uso a otra operacin
(caso de uso). Dicha relacin se denota con una flecha simple.
o Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase depende de otra, es decir, se
instancia (se crea). Dicha relacin se denota con una flecha punteada.
o Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin dependiendo de su
estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para actores).
Extends: Se recomienda utilizar cuando un caso de uso es similar a otro (caractersticas).
Uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que son similares en ms
de un caso de uso y no se desea mantener copiada la descripcin de la caracterstica.

Ejemplo:
Como ejemplo esta el caso de una Mquina Recicladora:
Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:
Registrar el nmero 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 botn de comienzo
Existe un operador que desea saber lo siguiente:
a. Cuantos temes han sido retornados en el da.
b. Al final de cada da el operador solicita un resumen de todo lo depositado en el da.
El operador debe adems poder cambiar:
a. Informacin asociada a temes.
b. Dar una alarma en el caso de que:
i. Item se atora.
ii. No hay ms papel.
Como una primera aproximacin identificamos a los actores que interactuan con el sistema:

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


Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar algn item por un cliente o
bien puede ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:


A qu nivel se describen los casos de uso?
No hay reglas explcitas 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 Diseo orientado a objetos (DOO).

Aprendizaje esperado: Construyen proyectos de software con enfoque en DOO, demostrando manejo de herramientas
de asistencia computarizada a la ingeniera para el anlisis y diseo OO.

2.1.- Define y conceptualiza los conceptos bsicos de DOO.

Diseo orientado a objetos es una etapa de la metodologa orientada a objetos en lo referente al desarrollo de Software.
Busca incentivar y ayudar a los programadores a pensar en trminos de objetos, en vez de procedimientos cuando definen
y planifican el cdigo. Un objeto agrupa datos encapsulados y procedimientos para representar una entidad.
La interfaz del objeto (las formas de interactuar con el objeto) tambin se definen en esta etapa. Un programa orientado a
objetos se caracteriza por la interaccin de esos objetos. El diseo 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 anlisis
orientado a objetos.

Fuente: Fundamentos del diseo de software, unidad 4 diseo orientado a objeto,
http://cufmingsoftware.wordpress.com/diseno-orientado-a-objeto/

Etapas del diseo orientado a objetos.
1. Planificacin y Especificacin de Requisitos: Planificacin, definicin de requisitos, conocer los procesos del
dominio, etc.
2. Construccin: La construccin del sistema. Se subdivide en las siguientes:
Anlisis: analizar el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que
van a solicitar servicios al sistema.
Diseo: Se especifica el diseo en detalle, describiendo cmo funcionar internamente para satisfacer lo
especificado en el anlisis.
Implementacin: Se lleva lo especificado en el diseo a un lenguaje de programacin.
Pruebas: Se realizan una serie de pruebas para corroborar que el software funciona correctamente y que
satisface lo especificado en la etapa de Planificacin y Especificacin de Requisitos.
3. Instalacin: 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 bsicos y necesarios en el diseo de sistemas con orientacin a objetos.

Principios del diseo 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 extensin y cerrada a la modificacin
Principio de Substitucin de Liskov: Cada clase que hereda de otra puede usarse como su padre sin necesidad de
conocer las diferencias entre ellas
Principio de Inversin de Dependencia: Los mdulos de nivel superior no deben depender sino de las abstracciones.
Los detalles deben depender a su vez de las abstracciones, no al contrario

Principio de Segregacin de Interfaces: La implementacin 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 Distribucin: Solo los componentes que se distribuyen de manera final pueden
ser reutilizados, el elemento mas importante es entonces el paquete.

Principio de Cierre Comn: Los componentes que comparten funciones entre ellos o que dependen uno del otro
deberan ser colocados juntos

Principio de Reuso Comn: Si se reutiliza una clase de un paquete entonces se reutilizan todas

Principio de Dependencias acclicas: 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 ms estables
Principio de Abstraccin Estable: Los paquetes deben ser ms abstractos mientras mas estables son

2.3.- Define, conceptualiza y aplica el concepto de arquitectura sobre el diseo con orientacin a objetos.

Arquitectura de 3 niveles

Busca ayudar a construir componentes fsicos a partir de los niveles lgicos. Se toman decisiones sobre qu parte lgica
de la aplicacin 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.
Ventajas de las Tcnicas Orientada a Objetos Desventajas de las Tcnicas Orientada a Objetos
Reutilizacin
Estabilidad
Comportamiento de objetos
Construccin de clases ms complejas
Confiabilidad
Nuevos mercados de software
Rpido diseo
Mayor calidad de diseo
Integridad
Programacin ms sencilla
Mantenimiento ms sencillo
Alta curva de aprendizaje
Costosa
Requiere conocimientos adicionales
No recomendable para proyectos pequeos
Requiere personal especializado


Nivel de Usuario
Los componentes del nivel de usuario, proporcionan la interfaz visual que los clientes utilizarn para ver la
informacin 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 tpicas tareas con los datos: Insercin, modificacin, consulta y borrado. Un
nivel de servicios de datos apropiadamente implementado, debera permitir cambiar su localizacin sin afectar a los
servicios proporcionados por los componentes de negocio.

Ventajas
Los componentes de la aplicacin pueden ser desarrollados en cualquier lenguaje.
Los componentes son independientes.
Los componentes pueden estar distribuidos en mltiples 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 administracin de los recursos cuando existe mucha concurrencia.
Permite reutilizacin 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 situacin mas comn de lo que uno cree, incluso se puede llevar esta situacin a la vida misma.
Solo se debe utilizar una filosofa antigua:divide y vencers.
Lo que se debe hacer es dividir un modelo (lneas de cdigo, de casos de uso, clases, etc.) en varias partes agrupando
elementos que tengan algn 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 anlisis orientado a objetos, demostrando
capacidad de abstraccin.

Creacin de casos de uso

Crear casos de uso es una verdadera ciencia. No existen reglas absolutas. La idea es comunicar informacin 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 interacta con el negocio o sistema,
teniendo en cuenta el valor que esta interaccin le da al usuario o a otros grupos de inters.

Un Caso de uso es la historia de cmo un negocio o un sistema interacta 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 tambin 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 ms importante, ya que el actor humano representa las relaciones e
interacciones mas interesantes y difciles para los sistemas.

Ser estructurado para crear casos de uso, crear una larga lista de pasos de principio a fin.

Un caso de uso debera tener un nico flujo principal y mltiples flujos alternativos.

Ser cuidadoso con la sentencia if, ya que utilizarla ms de una vez en un flujo significa que se estn especificando
mltiples requerimientos, es poco legible. Se debe romper cada if en su propio flujo.

2.5.- Define, aplica y crea diagramas de colaboracin utilizando el anlisis orientado a objetos, demostrando capacidad de
abstraccin.

Diagrama de colaboracin: es una forma de representar interaccin entre objetos.

Muestra cmo las instancias especficas de las clases trabajan juntas para conseguir un objetivo comn.
Consiste especificar un contrato entre objetos
Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro.
Dicha implementacin es llamada "enlace".

Un Diagrama de Colaboracin muestra una interaccin ordenada y organizada basndose en los objetos que
interactan y los enlaces entre ellos.

UML Interacciones
Los objetos interactan entre s envindose mensajes.
Los objetos se conectan a travs de enlaces.

Mensaje: especfica transmisin de informacin entre objetos.

Enlace: especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.
Es una conexin semntica entre objetos.
Es una instancia de una relacin.
Puede contener los adornos de la relacin.

Elementos de un diagrama de colaboracin.

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

Iteracin: colocar un * antes del nmero de secuencia y una clusula de condicin, si es necesario. ej.
*[x>0].

Bifurcacin: los caminos alternativos tendrn el mismo nmero de secuencia, seguido del nmero de
subsecuencia, y se deben distinguir por una condicin.

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

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



2.6.- Define, aplica y crea diagramas de secuencia utilizando el anlisis orientado a objetos, demostrando capacidad de
abstraccin.

Diagrama de secuencia: indica mdulos 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 aplicacin. En el caso de una aplicacin para jugar al
ajedrez, se podran realizar diagramas de secuencia para jugar una partida o bien para acciones ms especficas 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 quin.
En el diagrama de secuencia no se ponen situaciones errneas (poner todos los detalles crea un diagrama muchas veces
imposible de entender). El diagrama puede acompaarse con un texto en el que se detallen todas estas situaciones
errneas y particularidades.

Fuente: Diagrama de secuencia, Jess Caceres Tello, depto. ciencias de la computacin, Universidad de Alcal.

2.7.- Disea un sistema sencillo utilizando los recursos de la orientacin a objetos, utilizando herramientas de asistencia
computarizada a la ingeniera.
2.8.- Crea un proceso de desarrollo de software, aplicando los conceptos de la orientacin a objetos.

Proceso de desarrollo de software

Define el qu, quin, cundo y cmo del desarrollo de software.
Cuatro actividades fundamentales que son comunes para todos los procesos de desarrollo de software:
Especificacin del software
Desarrollo del software
Validacin del software
Evolucin del software

Dividir un proyecto en mini-proyectos, ms fciles de manejar y completar.
Cada mini-proyecto es una iteracin.
Cada iteracin contiene todos los elementos de un proyecto normal:
Planificacin
Anlisis y diseo
Construccin
Integracin y pruebas
Versin del producto (interna o externa)

Cada iteracin genera una lnea base (baseline) que comprende una versin parcialmente completa del sistema final, y
toda la documentacin 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.



BIBLIOGRAFA

Ingeniera de software de presuman

Taller de Herramientas de Productividad

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Taller de Herramientas de Productividad

Enviado por

Direitos autorais:

Formatos disponíveis

Vicerrectora Acadmica

Cuaderno de Apuntes 2013

Você também pode gostar