lunes, 3 de diciembre de 2012
lunes, 26 de noviembre de 2012
El Proceso Unificado
El Proceso
Unificado de Desarrollo de Software (RUP)
Introducción
El Proceso Unificado es un proceso
de software genérico que puede ser utilizado para una gran cantidad de tipos de
sistemas de software, para diferentes áreas de aplicación, diferentes tipos de
organizaciones, diferentes niveles de competencia y diferentes tamaños de
proyectos.
Provee un enfoque disciplinado en la
asignación de tareas y resposabilidades dentro de una organización de
desarrollo. Su meta es asegurar la producción de software de muy alta calidad
que satisfaga las necesidades de los usuarios finales, dentro de un calendario
y presupuesto predecible.
El Proceso
Unificado tiene dos dimensiones (Figura 1):
·
Un eje
horizontal que representa el tiempo y muestra los aspectos del ciclo de vida
del proceso a lo largo de su desenvolvimiento
·
Un eje
vertical que representa las disciplinas, las cuales agrupan actividades de una
manera lógica de acuerdo a su naturaleza.
La primera dimensión representa el
aspecto dinámico del proceso conforme se va desarrollando, se expresa en
términos de fases, iteraciones e hitos (milestones).
La segunda dimensión representa el
aspecto estático del proceso: cómo es descrito en términos de componentes del
proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.
El Proceso Unificado se basa en
componentes (component-based), lo que significa que el sistema en construcción
está hecho de componentes de software interconectados por medio de interfaces
bien definidas (well-defined interfaces).
El Proceso Unificado usa el Lenguaje
de Modelado Unificado (UML) en la preparación de todos los planos del sistema.
De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados
a la par.
Los aspectos distintivos del Proceso
Unificado están capturados en tres conceptos clave: dirigido por casos de uso
(use-case driven), centrado en la arquitectura (architecture-centric), iterativo
e incremental. Esto es lo que hace único al Proceso Unificado.
El Proceso Unificado es dirigido por
casos de uso
Un sistema de software se crea para
servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe
conocer qué es lo que quieren y necesitan los usuarios prospectos.
El término usuario se refiere no
solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el
término usuario representa algo o alguien que interactúa con el sistema por
desarrollar.
Un caso de uso es una pieza en la funcionalidad del sistema que le da
al usuario un resultado de valor. Los casos de uso capturan los requerimientos
funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa
del sistema. Este modelo reemplaza la tradicional especificación funcional del
sistema. Una especificación funcional tradicional se concentra en responder la
pregunta: ¿Qué se supone que el sistema debe hacer? La estrategia de casos de
uso puede ser definida agregando tres palabras al final de la pregunta: ¿por
cada usuario? Estas tres palabras tienen una implicación importante, nos
fuerzan a pensar en términos del valor a los usuarios y no solamente en
términos de las funciones que sería bueno que tuviera. Sin embargo, los casos
de uso no son solamente una herramienta para especificar los requerimientos del
sistema, también dirigen su diseño, implementación y pruebas, esto es, dirigen
el proceso de desarrollo.
Aún y cuando los casos de uso
dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la
par con la arquitectura del sistema, esto es, los casos de uso dirigen la
arquitectura del sistema y la arquitectura del sistema influencia la elección
de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de
uso maduran conforme avanza el ciclo de vida.
El Proceso Unificado está centrado en la
arquitectura
El papel del arquitecto de sistemas
es similar en naturaleza al papel que el arquitecto desempeña en la construcción
de edificios. El edificio se mira desde diferentes puntos de vista: estructura,
servicios, plomería, electricidad, etc. Esto le permite al constructor ver una
radiografía completa antes de empezar a construir. Similarmente, la
arquitectura en un sistema de software es descrita como diferentes vistas del
sistema que está siendo construido.
El concepto de arquitectura de
software involucra los aspectos estáticos y dinámicos más significativos del
sistema. La arquitectura surge de las necesidades de la empresa, tal y como las
interpretan los usuarios y otros stakeholders, y tal y como están reflejadas en
los casos de uso. Sin embargo, también está influenciada por muchos otros
factores, tales como la plataforma de software en la que se ejecutará, la disponiblidad
de componentes reutilizables, consideraciones de instalación, sistemas legados,
requerimientos no funcionales (ej. desempeño, confiabilidad). La arquitectura
es la vista del diseño completo con las características más importantes hechas
más visibles y dejando los detalles de lado. Ya que lo importante depende en
parte del criterio, el cual a su vez viene con la experiencia, el valor de la
arquitectura depende del personal asignado a esta tarea. Sin embargo, el
proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como
claridad (understandability), flexibilidad en los cambios futuros (resilience)
y reuso.
¿Cómo se relacionan los casos de uso
con la arquitectura? Cada producto tiene función y forma. Uno sólo de los dos
no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un
producto exitoso. En este caso función corresponde a los casos de uso y forma a
la arquitectura. Existe la necesidad de intercalar entre casos de uso y
arquitectura. Es un problema del “huevo y la gallina”. Por una parte, los casos
de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra
parte, la arquitectura debe proveer espacio para la realización de todos los
casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de
uso deben evolucionar en paralelo.
El Proceso Unificado es Iterativo e
Incremental
Desarrollar un producto de software comercial
es una tarea enorme que puede continuar por varios meses o años. Es práctico
dividir el trabajo en pequeños pedazos o mini-proyectos. Cada mini-proyecto es
una iteración que finaliza en un incremento. Las iteraciones se refieren a
pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el
producto. Para ser más efectivo, las iteraciones deben estar controladas, esto
es, deben ser seleccionadas y llevadas a cabo de una manera planeada.
Los desarrolladores basan su
selección de qué van a implementar en una iteración en dos factores. Primero,
la iteración trata con un grupo de casos de uso que en conjunto extienden la
usabilidad del producto. Segundo, la iteración trata con los riesgos más
importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo
a partir del estado en el que fueron dejados en la iteración anterior.
En cada iteración, los
desarrolladores identifican y especifican los casos de uso relevantes, crean el
diseño usando la arquitectura como guía, implementan el diseño en componentes y
verifican que los componentes satisfacen los casos de uso. Si una iteración
cumple sus metas – y usualmente lo hace – el desarrollo continúa con la
siguiente iteración. Cuando la iteración no cumple con sus metas, los
desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.
Conclusión
Los conceptos anteriormente tratados
– dirigido por casos de uso, centrado en arquitectura, desarrollo iterativo e
incremental – son igualmente importantes. La arquitectura provee la estructura
sobre la cual guiar el trabajo en iteraciones, mientras que los casos de uso
definen las metas y dirigen el trabajo en cada iteración. Remover cualquiera de
estos conceptos reducirá severamente el valor del Proceso Unificado. Es como
una mesa de tres patas, sin alguna de ellas, la mesa se caerá.
Tema10-El diseño de sistema usando UML
INTRODUCCION
Desde los
inicios de la informática se han estado utilizando distintas formas de
representar los diseños de una manera más bien personal o con algún modelo gráfico, La falta de
estandarización en la representación gráfica de un modelo impedía que los
diseños gráficos realizados se pudieran compartir
fácilmente entre distintos diseñadores, con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language).
UML es el lenguaje de modelado de sistemas de software más conocido en la actualidad; es el estándar
internacional aprobado por la OMG (Object Managment Group), consorcio creado en
1989 responsable de la creación, desarrollo y revisión de especificaciones para
la industrial del software.
UML son un grupo de especificaciones de notación
orientadas a Objeto, las cuales están compuesta por distintos diagramas, que representan las diferentes
etapas del desarrollo de un proyecto de software. Este trabajo se centra en un Sistema de Control de Citas Médicas. Se han usados
varios de los diagramas de UML, de modo que se muestre el uso de los mismos,
enfocado desde una perspectiva práctica.
El lenguaje
UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la
compañía Rational fundada por Booch (dos reputados investigadores en el área de
metodología del software). El objetivo de amb
os era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling
Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro
reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas
suyas. Estas tres personas son conocidas como los "tres amigos".
Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas
estas colaboraciones condujeron a la definición de la primera versión de UML.
1.
Modelado: es el diseño de un software antes de su codificación, es la visualización de lo que se
quiere construir.
Esta primera
versión se ofreció a un grupo de trabajo para convertirlo en 1997 en un
estándar del OMG. Este grupo gestiona estándares relacionados con la tecnología orientada a objetos (metodologías, bases de datos objetuales, CORBA, etc.), propuso
una serie de modificaciones y una nueva versión de UML (la 1.1), que fue
adoptada por el OMG como estándar en noviembre de 1997. Desde aquella versión
han habido varias revisiones que gestiona la OMG Revision Task Force. La última
versión aprobada es la UML 2.0 superstructure. En estos momentos se está
desarrollando actualizaciones a esta versión en la que se incluirán cambios
importantes (principalmente añadir nuevos diagramas).
Desarrollar el diseño y modelación
de un Sistema de Control de Citas Médicas utilizando el lenguaje UML.- Impulsar el acercamiento hacia una nueva manera de entender el diseño de software basado en UML.
OBJETIVOS
ESPECIFICOS
- Estudiar el lenguaje de Modelado UML.
- Desarrollar por completo el diseño de un proyecto de software con el fin de comprender todo el proceso.
- Identificar en el diseño del proyecto los distintos tipos de diagramas que existen como son los:
·
- Diagramas de clases
- Casos de usos
- Paquetes
- Diagramas de interacción y secuencia, y los diagramas de transición de estados
- Aplicar patrones de diseño modernos para la construcción de una aplicación de software utilizando para ello la herramienta Rational Rose.
- Mostrar como UML crea un protocolo de comunicación estándar entre los desarrolladores.
El trabajo
presentado a continuación es un estudio sobre el Lenguaje de Modelado que
abarca desde la definición de sus conceptos hasta su aplicación en un ejemplo
práctico, en el mismo veremos como UML nos permite experimentar y visualizar un
sistema que aun no ha sido codificado.
- Diseño de Sistema utilizando UML
·
- Historia del UML
- Que es UML
- Bloques de Construcción UML
o
- Elementos Estructurales
- Elementos de comportamiento
- Elementos de agrupación
- Elementos de anotación
- Relaciones
- Diagramas
- Caso Practico de un Diseño de Software utilizando UML (Sistema de Control de Citas Medicas)
·
- Definición de los requerimientos del sistema.
- Los diagramas de casos y subcasos de uso.
- La descripción de los casos de uso.
- Diagrama Conceptual.
- Diagrama de Estructura Estática (de Clases).
- Diagrama de Interacción.
- Diagrama de Estados.
- Diagrama de Actividades.
Este trabajo
no incluye la codificación del Software, el mismo esta enfocado desde el punto
de vista del diseño.
Standish
Group, CHAOS Report nos muestra en su estudio del 2002 que el 26%
de los proyectos de software son exitosos, lo que
quiere decir que el 74% fallan. La razón básica por la que fallan los proyectos
se determina en la etapa de análisis y diseño del sistema.
Entendiendo
lo anterior, podemos decir que es necesario y obligatorio el mejorar la calidad del desarrollo de software y para
esto debemos adoptar procedimientos, metodologías y herramientas que permitan una estandarización en
la ingeniería de software, esto es precisamente
lo que ofrecen los lenguajes de modelado de software, un lenguaje común que
permite el crear una disciplina con estándares como existe en la
ingeniería civil, ingeniería eléctrica, etc.
Siendo UML
el estándar internacional para el modelado hemos decidido el desarrollar este
tema para este proyecto, veamos algunos de los beneficios que ofrece UML:
- Contaremos con un mejor entendimiento del riesgo del proyecto antes de construir el sistema
- Mejores tiempos totales de desarrollo (de 50% o mas)
- Podremos especificar la estructura y el comportamiento del sistema y comunicarlo a todos los integrantes del proyecto
- Se documentarán las decisiones de la arquitectura del proyecto
- Se obtendrá el "plano" del sistema
- Mejor soporte a la planeación y al control del proyecto
- Un aumento en la calidad del desarrollo
- Reducción en los costos económicos
Estas son
algunas de las razones por la cual es necesario adoptar UML como lenguaje de
modelado, otra razón importante es el hecho de que muchas compañías a la hora
de contratar servicios de desarrollo exigen que el
lenguaje de modelado utilizado sea UML.
Tarea 1.
Documentación: En esta
etapa se realizarán consultas bibliográficas relacionadas con el análisis y diseño de
sistemas de información con UML, a los fines de elaborar un
manual de UML con sus diagramas,
definición y ejemplos.
Tarea 2.
Análisis de requerimientos: En esta etapa se busca la necesidad del usuario y la forma en que se va a
presentar la solución.
Actividades:
- Identificar Casos de Uso del sistema
- Dar detalle a los casos de uso descritos
- Definir una interfaz inicial del sistema
- Desarrollar el modelo del mundo
- Validar los modelos
Tarea 3.
Diseño del sistema: en esta
etapa se define una subdivisión del sistema por funciones y la forma de comunicación para su
interacción.
Actividades:
- Identificar la arquitectura del sistema
- Definir los componentes del sistema
- Refinar los casos de uso (textualmente y en diagrama)
Tarea 4.
Diseño detallado: en esta
etapa se adecuará el análisis a las características específicas del software.
Actividades:
- Agregar detalles de implementación al modelo del mundo
- Desarrollar el modelo de interfaz
- Desarrollar los modelos de control, persistencia y comunicación
- Hardware
·
·
- Rational Rose(Software para el modelado)
Suscribirse a:
Comentarios (Atom)