Diseo de Sistemas

2014

Ing. Waldemar Espinoza
UNIVERSIDAD NACIONAL DE LOJA
AREA DE LA ENERGA LAS INDUSTRIAS Y LOS RECURSOS NATURALES NO
RENOVABLES
CARRERA DE INGENIERA EN SISTEMAS
Alumno: Fernando Adrin Carrin Chamba
Paralelo: A
Docente: Ing. Waldemar Espinoza
Tema: Resumen del captulo 1 y 2 del libro gua UML y patrones.
Deber Nro. 1
Captulo I
ANALISIS Y DISEO ORIENTADO A OBJETOS[1]
Aplicaciones de UML y patrones en el A/DOO
UML es una notacin visual estndar. Tan til como aprender una notacin, como disear sistemas orientados
a objetos, UML no es A/DOO o un mtodo, es simplemente una notacin. No es tan til aprender hacer
diagramas UML sintcticamente correctos y quizs una herramienta CASE para UML. Ciertas soluciones
contrastadas a problemas de diseo se pueden expresar como principios, heursticas o patrones de buenas
prcticas llamadas frmulas de solucin de problemas que codifican principios de diseo ejemplares.
El A/DOO est fuertemente relacionado con la actividad que es un requisito previo del anlisis de requisitos,
que incluye escribir casos de uso. El anlisis de los requisitos y el A/DOO requieren que se presenten en el
contexto de algn proceso de desarrollo.
La construccin de software conlleva innumerables habilidades y pasos ms all del anlisis de requisitos, el
A/DOO, y la programacin orientada a objetos.
Asignacin de responsabilidades.
Hay muchas posibles actividades y artefactos en una introduccin al A/DOO, y un gran nmero de principios y
directrices. Una habilidad clave y fundamental en el A/DOO es la asignacin cuidadosa de responsabilidades a
los componentes software.
En un proyecto real, un desarrollador podra no tener la oportunidad de abordar ningn otra actividad de
anlisis o diseo.


Diseo de Sistemas
2014

Ing. Waldemar Espinoza
Qu es anlisis y diseo?
El anlisis pone nfasis en una investigacin del problema y los requisitos, en vez de ponerlo en una solucin,
el anlisis es un trmino amplio y es ms adecuado calificarlo como anlisis de requisitos.
El diseo pone nfasis en una solucin conceptual que satisface los requisitos, en ves de ponerlo en la
implementacin. Como en el anlisis, es ms apropiado calificar el termino como diseo de objetos o diseo
de bases de datos.
Qu son el anlisis y el diseo orientados a objetos?
Durante el anlisis orientado a objetos, se presta especial atencin a encontrar y definir los objetos. Durante el
diseo orientado a objetos, se presta especial atencin a la definicin de objetos. Durante la implementacin o
programacin orientada a objetos, los objetos de diseo se implementan como una clase en java.
UML
El lenguaje unificado de modelado(UML) es un lenguaje para especificar, visualiza, construir y documentar los
artefactos de los sistemas software, as como para el modelado del negocio y otros sistemas no software.
UML es una notacin estndar para el modelado orientado a objetos. UML fue adoptado en 1997como
estndar para el OMG y continua definiendo en nuevas versiones.
Por qu no veremos mucho UML durante unos pocos captulos?
UML se aplica principalmente durante el A/DOO, precedido, normalmente, por el anlisis de
requisitos.
Captulo 2.
DESARROLLO ITERATIVO Y EL PROCESO UNIFICADO. [1]
El desarrollo iterativo es un enfoque para el desarrollo de software que requiere un entrenamiento y poseer
ciertos conocimientos, y juega un papel central en el modo en que se presenta el A/DOO.
El proceso unificado combina las practicas comnmente aceptadas como buenas practicas, tales como ciclo
de vida iterativo y desarrollo dirigido por el riesgo, en una descripcin consistente y bien documentada.
La idea ms importante del UP: desarrollo iterativo
El UP fomenta muchas prcticas, pero una destaca sobre las dems: el desarrollo iterativo. En este enfoque,
el desarrollo se organiza en una serie de mini proyectos cortos, de duracin fija llamadas iteraciones; el
resultado de cada uno es un sistema que puede ser probado, integrado y ejecutado.
El ciclo de vida iterativo se basa en la ampliacin y refinamiento sucesivos del sistema mediante mltiples
iteraciones, con retroalimentacin cclica y adaptacin como elementos principales que dirigen para converger
hacia un sistema adecuado.
Diseo de Sistemas
2014

Ing. Waldemar Espinoza
El resultado de cada iteracin es un sistema ejecutable, pero incompleto; no esta preparado para ser puesto
en produccin el sistema podra estar listo para su puesta en produccin hasta despus de muchas
iteraciones.
Cada iteracin aborda nuevos requisitos y amplia el sistema incrementalmente, una iteracin podra
ocasionalmente, volver sobre el software que ya existe y mejorarlo.
Aceptando los cambios: retroalimentacin y adaptacin
Esto no quiere decir que el desarrollo iterativo y el UP fomenten un proceso dirigido por una adiccin
de caractersticas de manera incontrolada y reactiva.
Cada iteracin conlleva la eleccin de un pequeo conjunto de requisitos y rpidamente disear,
implementar y probar. En las primeras iteraciones, la eleccin de los requisitos y el diseo podran no
ser exactamente lo que se desea al final.
Tener retroalimentacin es una etapa temprana es de gran importancia ya que aporta un conocimiento
prctico y crucial, y una oportunidad de modificar o adaptarla comprensin de los requisitos el diseo.
En consecuencia, el trabajo se desarrolla a lo largo de una serie de ciclos estructurados de construir
retroalimentar y adaptar.
beneficios del desarrollo iterativo
o Mitigacin tan pronto como sea posible de riesgos altos.
o Progreso visible en las primeras etapas.
o Una temprana retroalimentacin.
o El equipo no se ve abrumado por la parlisis del anlisis.
o El conocimiento adquirido en una iteracin se puede utilizar metdicamente.
Longitud de una iteracin y fijacin de la duracin
El UP recomienda que la duracin de una iteracin sea de dos a seis semanas. Menos de dos
semanas es difcil completar los trabajos suficientes para obtener resultados significativos y
retroalimentacin, ms de seis semanas la complejidad se hace abrumadora.
Una idea clave es que se fija la duracin de las iteraciones. Equipos muy grandes podran requerir
iteraciones de ms de seis semanas para compensar los costes fijos de coordinacin y comunicacin,
pero no se recomienda que sea ms de tres a seis semanas.
Una iteracin de seis meses es la excepcin, en el caso de grandes equipos. El UP recomienda que la
duracin de una iteracin sea entre dos y seis semanas.
Conceptos y buenas prcticas del UP adicionales
Algunos conceptos claves y buenas prcticas del UP son:
Abordar cuestiones de alto riesgo y muy valiosas en las primeras iteraciones.
Involucrar continuamente a los usuarios para la evolucin, retroalimentacin y requisitos.
Construir las primeras iteraciones una arquitectura que construya un ncleo central existente.
Aplicar casos de uso.
Modelar software visual.
Gestionar los requisitos con cuidado.
Diseo de Sistemas
2014

Ing. Waldemar Espinoza
Manejar peticiones de cambio y gestin de configuraciones.
Las fases del UP y trminos orientados a la planificacin
1. Inicio: visin aproximada, anlisis del negocio, alcance, estimaciones impresisas.
2. Elaboracin: visin refinada, implementacin iterativa del ncleo central de la arquitectura.
3. Construccin: implementacin iterativa del resto de requisitos de menor riesgo y elementos mas
fciles.
4. Transicin: pruebas beta, despliegue.
La fase de inicio no es una fase de requisitos; sino una especie de fase de viabilidad. La fase de elaboracin
no es la fase de requisitos o de diseo; sino que es una fase donde se implementa, de manera iterativa, la
arquitectura que constituye el ncleo central y se mitigan las cuestiones de alto riesgo.
Las disciplinas del UP(eran flujos de trabajo)
El UP describe actividades de trabajo, como escribir casos de uso, en disciplinas. En el UP un artefacto es el
trmino general para cualquier producto del trabajo: grficos Web, esquema de base de datos, documentos de
texto, diagramas entre otros.
Modelado del negocio: cuando se desarrolla una nica aplicacin, esto incluye el modelado de los
objetos del dominio.
Requisitos: anlisis de los requisitos para una aplicacin.
Diseo: todos los aspectos del diseo, incluyendo la arquitectura global.
En el UP, Implementacin significa programar y construir el sistema, no despliegue. La disciplina Entorno se
refiere a establecer las herramientas y adaptar el proceso al proyecto.
Disciplina y fases
Las primeras iteraciones, naturalmente tienden aplicar un esfuerzo relativo mayor a los requisitos y al
diseo, y en las posteriores disminuye cuando los requisitos y el diseo central se estabilizan,
mediante un proceso de retroalimentacin. Durante la construccin se le da una importancia mayor a
la implementacin y ms ligera al anlisis de requisitos.
Adaptacin del proceso y el marco de desarrollo
Artefactos opcionales
Algunas prcticas y principios del UP deben seguirse siempre, como el desarrollo iterativo y dirigido
por el riesgo, y la verificacin continua de la calidad.
El conjunto de artefactos posibles del UP debera entenderse como un conjunto de medicinasen una
farmacia. Exactamente igual que uno no toma medicinas indiscriminadamente, sin que las elige segn
su dolencia, en un proyecto UP, un equipo debera seleccionar un pequeo conjunto de artefactos que
le sirvan para tratar sus problemas.


Diseo de Sistemas
2014

Ing. Waldemar Espinoza
El marco de desarrollo
La eleccin de artefactos del UP de un proyecto podra recogerse en un documento breve
denominado marco de desarrollo. Un proyecto de desarrollo nuevo, en un campo en el que no se
tenga experiencia tendra necesidades muy diferentes, en cuanto a los artefactos de diseo.
El UP gil
Los metodologas distinguen entre procesos pesados y ligeros, y procesos predictivos y adaptables. Un
proceso predictivo es aquel que intenta planifica y predecir en detalle las actividades y asignacin de recursos
en un intervalo relativamente largo de tiempo.
La intencin de los autores del UP no era que fuese pesado o predictivo, aunque su amplio conjunto de
actividades y artefactos opcionales, comprensiblemente, ha llevado algunos a tener esta impresin.
El ciclo de vida en cascada secuencial
A diferencia del ciclo de vida iterativo del UP, una antigua alternativa era el ciclo de vida en cascada, lineal o
secuencial, de la siguiente forma:
Determinar, registrar y acordar un conjunto de requisitos completo y fijo.
Disear un sistema basado en estos requisitos.
Implementar en base al diseo.
No se entendi el UP cuando
Signos que indican que no se ha entendido adoptar el UP:
Se piensa que inicio = requisitos, elaboracin = diseo, y construccin = implementacin.
Se piensa que el objetivo de la elaboracin es definir modelos de manera completa y cuidadosa, los
cuales se traducen a cdigo durante la elaboracin.
Se intenta definir la mayora de los requisitos antes de comenzar con el diseo o la implementacin.
Se dedica mucho tiempo a realizar trabajos sobre los requisitos y el diseo antes de comenzar a
programar.
Se cree que una iteracin adecuada es de cuatro meses de duracin, en lugar de cuatro semanas.
Se piensa que realizar los diagramas UML y las actividades de diseo constituyen el momento para
definir diseos y modelos de manera completa y precisa con gran detalle.
Se requieren planes y estimaciones crebles para proyectos antes de que termine la fase de
elaboracin.
BIBLIOGRAFIA
[1] Craig Larman, "Una introduccion al analisis y diseno orientado a objetos y al proceso unificado," in UML
y Patrones, Pearson Educacin, Ed. segunda, ch. 1-2, p. 590.