jueves, 25 de junio de 2009
sábado, 20 de junio de 2009
sábado, 16 de mayo de 2009
martes, 5 de mayo de 2009
miércoles, 29 de abril de 2009
Historia UML
HISTORIA UML
Se deriva y unifica las tres metodologías de análisis y diseño OO más extendidas:
• Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
• Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).
• Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compa nía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar una meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de una meta-modelo auto-referencial.
Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage). UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.
El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.
HISTORIA CASOS DE USO
En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de caso de uso. Se han realizado muchas mejoras al concepto que se estableció entonces, pero probablemente la más influyente y significativa, en términos de definición del término caso de uso, fue la de Alistair Cockburn en el libro Escribir casos de uso efectivos publicados en el año 2000.
Durante los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
Propósito general debería ser capaz de modelarse a sí mismo).
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por los ingenieros de requisitos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso del uso describe una característica del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso del uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.
Un caso de uso debe:
• describir una tarea del negocio que sirva a una meta de negocio
• tener un nivel apropiado del detalle
• ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:
• Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
• Un caso de uso extiende otro caso de uso.
• Un caso de uso usa otro caso de uso.
Se deriva y unifica las tres metodologías de análisis y diseño OO más extendidas:
• Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
• Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).
• Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacobson y su compa nía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.
De las tres metodologías de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración. Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de facto para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar una meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de una meta-modelo auto-referencial.
Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Con este objetivo se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Lan-guage). UML se ha convertido en ese estándar tan ansiado para representar y modelar la información con la que se trabaja en las fases de análisis y, especialmente, de diseño.
El lenguaje UML tiene una notación gráfica muy expresiva que permite representar en mayor o menor medida todas las fases de un proyecto informático: desde el análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc., hasta la implementación y configuración con los diagramas de despliegue.
HISTORIA CASOS DE USO
En 1986, Ivar Jacobson, importante contribuyente al desarrollo de los modelos de UML y proceso unificado, creó el concepto de caso de uso. Se han realizado muchas mejoras al concepto que se estableció entonces, pero probablemente la más influyente y significativa, en términos de definición del término caso de uso, fue la de Alistair Cockburn en el libro Escribir casos de uso efectivos publicados en el año 2000.
Durante los años 1990 los casos de uso se convirtieron en una de las prácticas más comunes para la captura de requisitos funcionales, especialmente con el desarrollo del paradigma de la programación orientada a objetos, donde se originaron, si bien puede utilizarse con resultados igualmente satisfactorios con otros paradigmas de programación.
Propósito general debería ser capaz de modelarse a sí mismo).
Los casos de uso evitan típicamente la jerga técnica, prefiriendo la lengua del usuario final o del experto del campo del saber al que se va a aplicar. Los casos del uso son a menudo elaborados en colaboración por los ingenieros de requisitos y los clientes.
Cada caso de uso se centra en describir cómo alcanzar una única meta o tarea de negocio. Desde una perspectiva tradicional de la ingeniería de software, un caso del uso describe una característica del sistema. Para la mayoría de proyectos de software, esto significa que quizás a veces es necesario especificar diez o centenares de casos de uso para definir completamente el nuevo sistema. El grado de la formalidad de un proyecto particular del software y de la etapa del proyecto influenciará el nivel del detalle requerido en cada caso de uso.
Los casos de uso pretenden ser herramientas simples para describir el comportamiento del software o de los sistemas. Un caso del uso contiene una descripción textual de todas las maneras que los actores previstos podrían trabajar con el software o el sistema. Los casos del uso no describen ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se implementará. Simplemente muestran los pasos que el actor sigue para realizar una tarea.
Un caso de uso debe:
• describir una tarea del negocio que sirva a una meta de negocio
• tener un nivel apropiado del detalle
• ser bastante sencillo como que un desarrollador lo elabore en un único lanzamiento
Situaciones que pueden darse:
• Un actor se comunica con un caso de uso (si se trata de un actor primario la comunicación la iniciará el actor, en cambio si es secundario, el sistema será el que inicie la comunicación).
• Un caso de uso extiende otro caso de uso.
• Un caso de uso usa otro caso de uso.
miércoles, 15 de abril de 2009
Taller UML
UML
(Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software.Entre otras palabras, UML se utiliza para definir un sistema de software.
CASOS DE USO
Los casos de uso son una técnica para especificar el comportamiento de un sistema:
Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios.
Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistemalo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.
1.De un ejemplo de caso de un caso de uso (practico)
2.Para que sirve UML.
Para representar visualmente las reglas de creacion de manera eficiente en la complejidad de un sistema u organizacion y asi mantener agilmente especificaciones
ante la arquitectura de los diagramas en un proceso.
Para que sirve los Casos De Uso.
Estos casos de usos nos sirven para documentar un proceso que se esta llevando en un sistema en el que determina los requisitos que el usuario esta solicitando ademas le provee al el usuario un mejor entendimiento.
3.Mensiones 4 ventajas y 4 desventajas de un caso de uso.
ventajas
facilidad de interpretacion
planear mejor las iteraciones
identificacion de funcionalidad de los pasos del sistema
ayuda a descubrir los componentes necesarios
desventajas
La relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los clientes.
En ocaciones es difícil establecer una secuencia temporal
no determina del todo los requerimientos de cliente
puede que haga falta de pruebas para generar el sistema
4.Mencionar Temas vistos con sergio.
Casos de Uso
Diagramas de Clase
Uso de Relaciones
(Unified Modeling Language - Lenguaje Unificado de Modelado). UML es un popular lenguaje de modelado de sistemas de software. Se trata de un lenguaje gráfico para construir, documentar, visualizar y especificar un sistema de software.Entre otras palabras, UML se utiliza para definir un sistema de software.
CASOS DE USO
Los casos de uso son una técnica para especificar el comportamiento de un sistema:
Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios.
Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistemalo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.
1.De un ejemplo de caso de un caso de uso (practico)
2.Para que sirve UML.
Para representar visualmente las reglas de creacion de manera eficiente en la complejidad de un sistema u organizacion y asi mantener agilmente especificaciones
ante la arquitectura de los diagramas en un proceso.
Para que sirve los Casos De Uso.
Estos casos de usos nos sirven para documentar un proceso que se esta llevando en un sistema en el que determina los requisitos que el usuario esta solicitando ademas le provee al el usuario un mejor entendimiento.
3.Mensiones 4 ventajas y 4 desventajas de un caso de uso.
ventajas
facilidad de interpretacion
planear mejor las iteraciones
identificacion de funcionalidad de los pasos del sistema
ayuda a descubrir los componentes necesarios
desventajas
La relaciones hace que los diagramas sean más difíciles de leer, sobre todo para los clientes.
En ocaciones es difícil establecer una secuencia temporal
no determina del todo los requerimientos de cliente
puede que haga falta de pruebas para generar el sistema
4.Mencionar Temas vistos con sergio.
Casos de Uso
Diagramas de Clase
Uso de Relaciones
Suscribirse a:
Comentarios (Atom)