Apuntes Parcial 2 Análisis de sistemas I

[pic 1]                                                                                      [pic 2]

Universidad Autónoma de Nuevo León

Facultad de Ciencias Físico Matemáticas

Apuntes

Parcial 2

  Análisis de sistemas I

P.T.B. José Angel Hernández Trejo

Mat: 1837472

domingo, 12 de marzo de 2017

[pic 3]

[pic 4]

[pic 5]

[pic 6]

[pic 7]

[pic 8]

[pic 9]

[pic 10]

[pic 11]

[pic 12]

[pic 13]

[pic 14]

[pic 15]

[pic 16]

[pic 17]

[pic 18]

[pic 19]

[pic 20]

[pic 21]

[pic 22]

[pic 23]

[pic 24]

[pic 25]                                                                              [pic 26]

Competencias

domingo, 12 de marzo de 2017         19:02:54

                                                                                 [pic 27][pic 28]

Universidad Autónoma de Nuevo León

Facultad de Ciencias Físico Matemáticas

Análisis de Sistemas I – Competencia 5

Ing. Juan Jesús de la Garza Ochoa M.T.

José Angel Hernández Trejo

Mat: 1837472

Fernando Dilland Mireles Cisneros

Mat: 1837532

Franco Adolfo Martínez García

Mat: 1721962

ANÁLISIS DE SISTEMAS I

GRUPO 002 - AULA 114 – Ju – 15:00 a 18:00 hrs.

Segundo Parcial– COMPETENCIA 5

Modelado de sistemas con UML

Significado de las siglas: Lenguaje Unificado de Modelado.

El Lenguaje Unificado de Modelado prescribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan. Mientras que ha habido muchas notaciones y métodos usados para el diseño

orientado a objetos, ahora los modeladores sólo tienen que aprender una única notación. UML se puede utilizar para modelar diferentes tipos de sistemas: sistemas de software, sistemas de hardware y organizaciones del mundo real. UML ofrece nueve diagramas para modelar sistemas.

Diferentes tipos de diagramas encontrados:

• Diagramas de Casos de Uso para modelar los procesos ’business’.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.

La misma también fue creado por tres personajes que desarrollaron nociones muy diferentes de análisis pero que al unirlas llegaría al lenguaje del modelado, los nombres de estos personajes son Booch el desarrollo del libro en el análisis y el diseño orientado a objetos, James Rumbaugh técnica de modelado de objetos, Jacobson orientada a objetos de ingeniería de software.

En 1996, el Object Management Group (OMG), un pilar estándar para la comunidad de diseño orientado a objetos, publicó una solicitud orientada a objetivos para un meta modelo orientado a objetos de semántica y notación estándar. UML, versión 1.0, se propuso como respuesta a esta solicitud en enero de 1997. Hubo otras cinco propuestas competitivas. Durante el transcurso de 1997, los seis promotores de las propuestas, se unieron a su trabajo y presentaron al OMG un documento UML revisado, denominado UML versión 1.1. Este documento fue aprobado por el OMG en noviembre de 1997. El OMG llama a este documento OMG UML versión 1.1. El OMG está actualmente en proceso de mejorar una edición técnica de esta especificación, cuya finalización está prevista para el 1 de abril de 1999.

Aparte, muchas organizaciones han desarrollado sus propias metodologías internas, usando diferentes diagramas y técnicas con varios orígenes. Ejemplos son el método Catalyst de Computer Sciences Corporation (CSC) o el World Wide Solution Design y método de entrega (WSDDM) de IBM. Estas metodologías difieren, pero generalmente combinan análisis de flujo de trabajo, captura de requisitos y modelado de negocio con modelado de datos, modelado de objetos usando varias notaciones (OMT, Booch, etc.) ya veces incluyendo técnicas de modelado adicionales. . La mayoría de estas organizaciones están adoptando e incorporando el UML como la notación orientada a objetos de sus metodologías.

La propuesta metodología de modelado en tiempo real ha sido formulada usando UML (Unified Modeling Language) con el fin de integrar conceptualmente con representaciones Sistemas funcionales, de despliegue y de realización para sistemas orientados a objetos que el lenguaje como un estándar de representación, y también ser apoyado por herramientas Común. El lenguaje UML se ha utilizado en dos sentidos. En primer lugar, se ha utilizado para Conceptualmente definir los elementos de modelado a través de un meta modelo formal, de los cuales, el modelo de cualquier sistema es una instancia, y en segundo lugar se ha utilizado como

Lenguaje con el que se formulan los últimos modelos.

Es importante señalar que UML es "lenguaje de modelado" indicar o describir el método o proceso. Se utiliza para definir el sistema para obtener detalles de los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que describe el modelo.

• Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

• Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.

• Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

• Análisis: La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
• Diseño: En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

• Programación: En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

• Pruebas: Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

Los diagramas se dividen llegando hacer solamente 6 diagramas los que se utilizan, su uso va de acuerdo a las necesidades propias de cada sistema, lo ideal es lograr una buena explicación del sistema gráficamente expresada.

...