Desarrollo de sistemas de información

627 views
451 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
627
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 3 Core Message: Modeling captures essential parts of the system Key Point 1: Computer system basically automate business processes. However, it’s not easy to build software systems on time and within budget. Key Point 2: Building a complex software system requires blueprint. You don’t construct a building without a blueprint. Visual modeling is the blueprint for software systems. Conclusion: VM is a key to successful software development
  • 9 Core message -- second bullet UML can be used to communicate system and software design throughout the life cycle
  • 10 Walk the audience through the timeline. Point out that the UML is the natural successor to the notations. 1. Late ‘80s and early ‘90 - there are many (50+) OO methodologies 2. Among the first generation methodologies, Booch and OMT stood out 3. Around 1993, second generation methodologies came out - Booch ‘93 and OMT-II. Methodologist borrowed good concepts from each others so many concepts were the same across the methodologies, but different notations. 4. Oct. 1994 - Dr. James Rumbaugh joined Rational to unify Booch & OMT. 5. At OOPSLA ‘95, Grady and Jim announced Unified Method 0.8. 6. Use Case technique developed by Dr. Ivar Jacobson was adapted by all methodologies by then. 7. Rational acquires Objectory in fall of ‘95 - Dr. Ivar Jaconson joins Rational. 8. Jun of ‘96 - Rational submits UML 0.9 to OMG. 9. UML gains industry support from HP, Microsoft, Oracle + 16 others 10. UML is the defacto standard for OO and component technologies 11. The final submission goes in Sep. ‘97 - expect the announcement in Dec.
  • 11 Transition: So! Who should use UML? Everybody who is doing software development. Core Message: UML supports object and component-based technology. Key Point 1: UML is an expressive language that can be used to describe pretty much everything about software application. - object technology: objet, class, relationships, scenario, Use Case - component-based development: component, ActiveX/COM, CORBA - large scale system, application partitioning
  • Desarrollo de sistemas de información

    1. 1. Ing. Carlos Avalos Ruiz 1 Tema Nro.1: Desarrollo de sistemas de información “Una guía para la automatización de las funciones de la organización para la obtención de ventajas competitivas”
    2. 2. Ing. Carlos Avalos Ruiz 2 Introducción • El desarrollo de los sistemas de información se basan en ciclo de vida del desarrollo del software. • La disciplina encargada de proveer los medios necesarios para la construcción de una software es la ingeniería de software. • Por ende el desarrollo de los sistemas de información están basado en procesos de desarrollo de software que la ingeniería de software propone. • Para ello existen dos enfoques paradigmáticos: estructurado y orientado a objetos.
    3. 3. Ing. Carlos Avalos Ruiz 3 La Ingeniería de Software (IS) • La IS es una disciplina que integra métodos, herramientas y procedimientos para el desarrollo del software de computadoras. • Se han propuesto varios paradigmas, entre ellos podemos mencionar: estructurado,orientado a objetos ,sala limpia, cliente/servidor, reutilización del software, reingeniería del software, software asistido por computa- doras, etc. • El software se ha convertido en el elemento clave de la evolución de los sistemas y productos informáticos.
    4. 4. Ing. Carlos Avalos Ruiz 4 Paradigma Orientado a Objetos • Con frecuencia se alude a la Orientación a Objetos como un nuevo paradigma (Paradigma de Objetos) y al término Orientado a Objeto ( OO ) como la aplicación de este paradigma al mundo de la computación. • El paradigma para los programadores, es la manera como se maneja la complejidad. • Desde este punto de vista el paradigma es el modelo o la estructura dentro del software solución de un problema.
    5. 5. Ing. Carlos Avalos Ruiz 5 • Superficialmente OO significa la organización del software como una colección de Objetos discretos que incorpora tanto la estructura de datos como su comportamiento. • Para cada entidad del dominio, hay un objeto que representa ese concepto en el modelo. • Finalmente, OO modela mirando en alguna parte realidad o dominio que es de interés, y busca las abstracciones claves y las relaciones entre esas abstracciones claves.
    6. 6. Ing. Carlos Avalos Ruiz 6 • La Orientación a Objetos se aplica a otros disciplinas dentro del mundo de la computación, tal como se aprecia en la siguiente ilustración :
    7. 7. Ing. Carlos Avalos Ruiz 7 En resumen la Orientación a Objetos: Orientado a objetos abstracción de la realidad Conceptos Objetos Clases Estructuras - jerárquicas Métodos/ope- raciones/servicios Abstracción Encapsulamiento Herencia Polimorfismo Mensaje Identidad Asociación en función y que mediante permite manejar la complejidad
    8. 8. Ing. Carlos Avalos Ruiz 8 Tecnología Orientada a Objetos • La Tecnología de Objetos (TO), una de las más recientes técnicas de desarrollo de sistemas y se basa en la OO; cuenta con cuatro bases fundamentales : – Análisis Orientado a Objetos (AOO). – Diseño Orientado a Objetos (DOO). – Programación Orientada a Objetos (POO). – Base de Datos Orientado a Objetos (BDOO).
    9. 9. Ing. Carlos Avalos Ruiz 9 Tecnología orientada a objetos Nuevos métodos de programación. Nuevos métodos de análisis Nuevos métodos de diseño Reutilizar el código Mas calidad Mas productividad Menos costo Situación Actual en la TOO
    10. 10. Ing. Carlos Avalos Ruiz 10 Desarrollo de la Tecnología Orientada a Objetos • Con el universo de métodos, se ha formado un cos- mo dinámico con el mundo de objeto en el que un método evoluciona en una estrella nítida u otra cesa para ser destacado y llega a ser un gigante rojo antes de desaparecer enteramente. • De aquí en adelante, una organización debería prime ra comprender completamente qué significa para pen sar desde el punto de vista de objetos.
    11. 11. Ing. Carlos Avalos Ruiz 11 Método, Metodología y Proceso en el desarrollo de software • Un método es la aplicación particular de una método logia de desarrollo de software pero que no abarca el ciclo de vida de desarrollo de software ni cuenta con herramientas tecnológica de soporte. • Una metodología es una marco general basado en un paradigma que sirve de base para el desarrollo de software y que abarca todo el ciclo de vida. • Un proceso de desarrollo de software esta basado en una metodología, abarca todo el ciclo de vida y provee herramientas tecnológica de soporte.
    12. 12. Ing. Carlos Avalos Ruiz 12 ¿Problemas en el desarrollo de software? • Retrasos en los plazos • Proyectos cancelados • Rápido deterioro del sistema instalado • Tasa de defectos o fallos • Requisitos mal comprendidos • Cambios frecuentes en el dominio del problema • Muchas de las interesantes características del software no proporcionan beneficios al cliente • Buenos programadores se cansan y dejan el equipo
    13. 13. Ing. Carlos Avalos Ruiz 13 El Modelado • El modelado es una tecnica de ingeniería probada y bien aceptada. • El modelado no solo es parte de la industria de la construcción. • Un modelo es una abstracción del sistema, especificando el sistema desde un cierto punto de vista y en un determinado nivel de abstracción. • Un modelo es una simplificacion de la realidad.
    14. 14. Ing. Carlos Avalos Ruiz 14 ¿Por qué las empresas no hacen modelado? • La mayor parte de las empresas software no realizan ningún modelado. • El modelado requiere: – aplicar un proceso de desarrollo – formación del equipo en la técnicas – ¿tiempo? • ¿Se obtienen beneficios con el modelado?
    15. 15. Ing. Carlos Avalos Ruiz 15 ¿Por qué modelamos? • Los modelos : • Ayudan a visualizar como es o queremos que sea el sistema. • Especifican la estructura o comportamiento de un sistema • Proporcionan plantilla que nos guian en la construccion de un sistema. • Documentan las decisiones que hemos adoptado. Construimos modelos para comprender mejor el sistema que estamos desarrollando.
    16. 16. Ing. Carlos Avalos Ruiz 16 Principio de Modelado • La elección de que modelos crear tiene una profunda influencia sobre como se define un problema y como se da forma a una solucion. • Todo modelo puede ser expresado a diferentes nive les de expresion. • Los mejores modelos están ligados a la realidad. • Un único modelo no es suficiente. • El modelado no es sólo para los grandes sistemas.
    17. 17. Ing. Carlos Avalos Ruiz 17 Sistema de Computo Procesos del Negocio Order Item Ship via “El modelado captura la parte escencial de un sistema.” Dr. James Rumbaugh El Modelado Visual es un modelamiento usando notaciones graficas estandares Modelado Visual
    18. 18. Ing. Carlos Avalos Ruiz 18 Arquitectura del Software • La visualización, especificación, construcción y documentación de un sistema con gran cantidad de software requiere que el sistema sea visto desde varias perspectivas. • La arquitectura de un sistema es quizás el artefacto mas importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo iterativo e incremental.
    19. 19. Ing. Carlos Avalos Ruiz 19 • La arquitectura es un conjunto de decisiones significativas sobre: – La organización de un sistema software. – La selección de elementos estructurales y sus interfaces a través de los cuales se constituye el sistema. – Su comportamiento, como se especifica en la colaboraciones entre esos elementos. – La composición de esos elementos estructurales y de comportamiento en subsistemas progresivamente mas grandes. – El estilo arquitectónico que guía esta organización: los elementos.
    20. 20. Ing. Carlos Avalos Ruiz 20 • estáticos y dinámicos y sus interfases, sus colaboraciones y su composición. • La arquitectura del software no tiene que ver sola mente con la estructura y el comportamiento, sino también con el uso, la funcionalidad, el rendimiento, la capacidad de adaptación, la reutilización, la capacidad de ser comprendido, las restricciones económicas y de tecnología y los compromisos entre alternativas, así como de los aspectos estáticos.
    21. 21. Ing. Carlos Avalos Ruiz 21 Modelado de la arquitectura de un sistema software Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso vocabulario funcionalidad ensamblado gestión conf. topología entrega distribución instalación Funcionamiento escalabilidad rendimiento comportamiento
    22. 22. Ing. Carlos Avalos Ruiz 22 • La vista de casos de uso de un sistema comprende los casos de uso que describen el comportamiento del sistema tal y como es percibido por los usuarios finales, analistas, y encargados de las pruebas. • La vista de diseño de un sistema comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y las solución. • La vista de procesos de un sistema comprende los hilos y procesos que forman los mecanismos de sincronización y concurrencia del sistema.
    23. 23. Ing. Carlos Avalos Ruiz 23 • La vista de implementación de un sistema compren de los componentes y archivos que se utilizan para ensamblar y hacer disponible el sistema físico. • La vista de despliegue de un sistema contiene los nodos que forman la topología hardware sobre la que se ejecuta el sistema. Cada una de estas cinco vistas pueden existir por si misma, de forma que diferentes usuarios pueden centrarse en las cuestiones de la arquitectura del sistema que mas le interese.
    24. 24. Ing. Carlos Avalos Ruiz 24 Por qué es necesaria la arquitectura • Un sistema software grande y complejo requiere una arquitectura para que los desarrolladores puedan progresa hasta tener una visión común. • Se necesita una arquitectura para: – Comprender el sistema. – Organizar el desarrollo. – Fomentar la reutilización. – Hacer evolucionar el sistema.
    25. 25. Ing. Carlos Avalos Ruiz 25 Unified Modeling Language (UML) • UML es un lenguaje estandar para la visualiza cion , especificacion, construccion, y documenta cion de artefactos de un sistema. • UML combina lo mejor de : – Modelamiento conceptual de datos (Diagrama Entidad Relacion) – Modelamiento del flujo de actividades. – Modelamiento de Objetos – Modelamiento de Componentes
    26. 26. Ing. Carlos Avalos Ruiz 26 • UML Significa Lenguaje Unificado de Modelado. Un lenguaje de modelado es lenguaje cuyo voca bulario y reglas se centra en la representación conceptual y física de un sis tema. • UML consiste en Reglas de simbología que se aplican a cualquier tipo de modelo hecho bajo este lenguaje. • UML es un Lenguaje estandar para escribir planos o modelos de software.
    27. 27. Ing. Carlos Avalos Ruiz 27 • UML tiene una sintaxis y una semántica bien definida. La parte mas visible de UML es su notación gráfica. • Puede utilizarse con todos los procesos y a lo largo del ciclo de vida del desarrollo de softwa re, y con diferentes tecnologias de implementa cion. • UML puede utilizarse para: – Visualizar el límite de un sistema y sus fun ciones importantes.
    28. 28. Ing. Carlos Avalos Ruiz 28 – Ilustrar realizaciones de un sistema. – Representar la estructura estática de un siste ma . – Modelar el comportamiento de objetos. – Conocer la arquitectura física de la implemen tación. – Extender su funcionalidad con estereotipos. • El vocabulario y las reglas de un lenguaje como UML indican como crear y leer modelos bien for mados, pero no dicen “que” ni “cuando” estos mo delos se deben crear.
    29. 29. Ing. Carlos Avalos Ruiz 29 • UML es sólo un lenguaje y por lo tanto estan sólo una parte de un método de desarrollo de Software. UML es independiente del proceso. • Un proceso bien definido guiará a sus usuarios al decidir qué artefactos producir, qué activida des y qué personal emplear para crearlo y ges tionarlo. • Un artefacto es una pieza de información que es utilizada o producida por un proceso de desarro llo de software.
    30. 30. Ing. Carlos Avalos Ruiz 30 Antecedentes de UML • Originalmente desarrollado por Rational, Grady Booch y James Rumbaugh. • Posteriormente se tiene la contribución de Ivar Jacobson. • Esta aceptada por OMG (Object Manage ment Group) • UML se ha publicado en las siguientes versiones: 0.8, 0.9, 0.91, 1.0, 1.1,1.2,1.3.......
    31. 31. Ing. Carlos Avalos Ruiz 31 Los tres amigos (y otros) • Ivar Jacobson -- Objectory and use cases. • Jim Rumbaugh -- OMT and UML. • Grady Booch -- Booch Method and UML. • Hewlett-Packard, Texas Instruments, Oracle. • Microsoft -- Repository, visual modeling. • Platinum -- OPEN Modeling Language. • IBM/ObjectTime -- OCL/ROOM.
    32. 32. Ing. Carlos Avalos Ruiz 32 Contribuciones Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Embley Singleton classes and high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Booch Booch method Jacobson OOSE
    33. 33. Ing. Carlos Avalos Ruiz 33 Historia de UML Booch method OMT Unified Method 0.8OOPSLA ´95 OOSEOther methods UML 0.9Web - June ´96 public feedback Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 UML 1.3 UML 1.0UML partners
    34. 34. Ing. Carlos Avalos Ruiz 34 Donde puede utilizarse UML • UML esta pensado principalmente para sistemas de gran cantidad de software. • UML es apropiado para modelar desde sistemas de información en empresas hasta aplicaciones distribuidas basadas en Web, e incluso para sistemas empotrados de tiempo real muy exigentes. • UML no esta limitado al modelado de software, es lo sufientemente expresivo para modelar sistemas que no son software.
    35. 35. Ing. Carlos Avalos Ruiz 35 Classes application partitioning Business Objects Relationships Business Process Objects Use Cases large scale system Scenarios Components Microsoft ActiveX/COM Microsoft ORDBMS Oracle CORBA OMG UML: Soporte para el desarrollo de cualquier tipo de aplicaciones
    36. 36. Ing. Carlos Avalos Ruiz 36 Utilidad de UML • Permite especificar todas las decisiones de análisis, diseño e implementación, construyéndose modelos precisos, no ambiguos y completos. • UML puede conectarse a lenguajes de programación: – Ingeniería directa e inversa • Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones,..)
    37. 37. Ing. Carlos Avalos Ruiz 37 Metamodelo UML • ¿Cómo se expresa la semántica del modelo? – Informalmente – Formalmente • El metamodelo UML define la notación de un modo riguroso, a través de diagramas de la propia notación y con OCL.
    38. 38. Ing. Carlos Avalos Ruiz 38 Metamodelo UML: Ejemplo Relación AsociaciónGeneralización Role de asociación 1 2..*ordered
    39. 39. Ing. Carlos Avalos Ruiz 39 Modelo Conceptual de UML • Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos principales: – Los bloques de construcción. – Las reglas que dictan como se pueden combinar estos bloques básicos. – Algunos mecanismos comunes que se pueden aplicar.
    40. 40. Ing. Carlos Avalos Ruiz 40 UML Elementos Estructural Use case Clases Clases Activas Interfaces Componentes Colaboraciones Nodos Comportamiento Agrupación Anotación Relaciones Diagramas Especificaciones Adornos Divisiones comunes Mecanismos de extensión Interacción Maquina de Estado Paquete Modelo Subsistema Framework Notas Dependencia Asociación Generalización Realización Use case Clases Objetos Secuencia Colaboraciones Estado Actividad Componentes Despliegue Estereotipos Valores etiquetados Restricciones Bloques de Construcción Reglas Nombres Alcance Visibilidad Integridad Mecanismos Comunes
    41. 41. Ing. Carlos Avalos Ruiz 41 Elementos del modelo conceptual de UML • Elementos estructurales: modelan partes estáticas y representan cosas conceptuales y materiales, son: Clases, una interfaz, una colaboración, un use case, componentes y nodos. • Elementos de comportamiento: son las partes dinámi cas de los modelos, representan comportamiento en el tiempo y el espacio, son: una interacción y una máquina de estados.
    42. 42. Ing. Carlos Avalos Ruiz 42 • Elementos de agrupación: son las partes organizati vas, el elemento de agrupación principal son los pa quetes. • Elementos de anotación: son las partes explícitas, se usan para describir, clarificar o hacer observaciones, esta es una nota
    43. 43. Ing. Carlos Avalos Ruiz 43 Elementos Estructurales Ventana origen tamaño abrir() cerrar() mover() dibujar() clase IAvisable <<Interface>> IAvisable Interface ValidarTransacción caso de uso Gestor Eventos suspender() vaciarCola() clase activa Gestión Pedidos colaboración componente Hola Mundo.class Servidor nodo
    44. 44. Ing. Carlos Avalos Ruiz 44 Elementos de Comportamiento Interacción Conjunto de mensajes intercambiados entre un conjunto de objetos con un propósito particular. mensaje dibujar Máquina de estados Secuencia de estados por las que pasa un objeto durante su vida en respuesta a eventos. estadoactivado
    45. 45. Ing. Carlos Avalos Ruiz 45 Elementos de Agrupamiento Modelo del Negocio Paquete Un paquete incluye un conjunto de elementos de cualquier naturaleza. Tiene una naturaleza conceptual.
    46. 46. Ing. Carlos Avalos Ruiz 46 Elementos de Notación Son las partes explicativas de los modelos UML NotaRetorna 0 si no existe el valor
    47. 47. Ing. Carlos Avalos Ruiz 47 Relaciones del modelo concpetual de UML Dependencias Asociaciones patrón empleado 0..1 * Generalizaciones Realización
    48. 48. Ing. Carlos Avalos Ruiz 48 Diagrama Use Case Diagrama de ColaboracionColaboracion Diagrama de Componentes Diagrama de Despliegue Diagrama de Objetos Diagrama de Estado Diagrama de Secuencia Diagrama de Clases Diagrama de Actividad Un modelo es una descripción completa de un sistema desde una perspectiva particular Modelos Modelos y Diagramas de UML
    49. 49. Ing. Carlos Avalos Ruiz 49 atributos operaciones dependencia Empresa generalización Oficina Principal 1 1..** 0..1 clase ** miembro rol 11..* {subgrupo} asociación administrador restricción multiplicidad agregación nombre 1..* sitio Empleado Nombre: María IDEmpleado: 2568 Cargo: Gerente obtenerFoto(f:Foto) obtenerSonido() obtenerContacto() obtenerRegistroEmpleados() Contacto Dirección: Pizarro 254 RegistroEmpleados IdImpuesto Historialempleado sueldo/salario Departamento Nombre: Ventas * Oficina Dirección : Sucre 360 Código: 2358 * Diagrama de Clases • Muestra un conjunto de clases, interfaces y colabora ciones con sus relaciones.
    50. 50. Ing. Carlos Avalos Ruiz 50 e: Empresa objeto anónimo valor de atributo enlace objeto d1: Departamento Nombre: “Ventas” d2: Departamento Nombre: “RRHH” d3: Departamento Nombre: “Ventas a Crédito” p: Personal Nombre = “Eddi” IDEmpleado = “4356” Cargo = “Vendedor” : Contacto Dirección:“Pio265” Diagrama de Objetos • Muestra un conjunto de objetos y sus relaciones.
    51. 51. Ing. Carlos Avalos Ruiz 51 Red celular Usuario actor Emitiendo llamadas de conferencia Recepcionando llamada adicional Usando horario Recibiendo llamada Emitiendo llamada Relación extendida <<extend>> <<extend>> use-case límites del sistema Telefonía Celularasociación Diagrama de Use Case • Muestra un conjunto de Casos de Uso (Use Case), actores y sus relaciones, presenta una descripción de la conducta de un sistema para un usuario en un punto determinado.
    52. 52. Ing. Carlos Avalos Ruiz 52 h : hilo : herramientas p : par a1 : ejecutar(3) ejecutar() <<create>> <<destroy>> pideIdent() rellamada() objeto etiqueta de la secuencia mensaje línea de vida creacion llamada recursión retorno/rspta destrucción enfoque de control interacción Diagrama de Secuencia • Es un diagrama de interacción que resalta el orden tem poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo.
    53. 53. Ing. Carlos Avalos Ruiz 53 Diagrama de Colaboraciones • Es un diagrama de interacción que resalta el orden tem poral de los mensajes, es decir, muestra el dinamismo de la interacción entre objetos, en función al tiempo. c:Cliente :Transacción p:ODBDProxy 1: <<create>> 2: grupoAcciones(a,d,o) 3: <<destroy>> <<global>> 2.1: grupoValores(d,3.4) 2.2: grupoValores(a,”CO”) objeto mensaje enlace <<local>> {transitorio} Diagrama de Colaboración
    54. 54. Ing. Carlos Avalos Ruiz 54 estado inicial conectado conectando Trabajando listo(3) [señal OK] Inactivo encender apagar/reconectar() activado/revisar() apagado estado final estado evento acción transición transición interna guardar estado anidado Máquina de Estado Diagrama de Estado • Muestra una máquina de estados, que consta de: esta dos, transiciones, eventos y actividades. Estos diagra mas cubren la vista dinámica del sistema. Son importan tes para modelar el comportamiento de una interfaz, cla se o colaboración.
    55. 55. Ing. Carlos Avalos Ruiz 55 estado inicial Seleccionar lugar Comisionar a arquitectos Desarrollar plan Ofertar plan Fin de construcción Trabajar el plan Negociar el plan() :Certificado de ocupación [terminado] ramas de secuencia [no aceptado] [else] flujo de objeto estado de actividad con submáquina estado final bifurcación concurrente unión concurrente estado de la acción Diagrama de Actividades • Es un tipo especial de diagrama de estado que muestra el flujo de actividades dentro de un sistema. Son especialmente impor tantes al mode lar el funcionamiento de un sistema pues resaltan el flujo de control entre objetos.
    56. 56. Ing. Carlos Avalos Ruiz 56 hallar.exe índice.html hallar.html accesoBd.dll busca.dll <<hiperenlace>> ejecutable página web librería componente Diagrama de Componentes • Muestra la orga nización y las dependencias entre un conjun to de componen tes. Presentan la vista estática de implementación del sistema.
    57. 57. Ing. Carlos Avalos Ruiz 57 <<processor>> servidor primario <<processor>> servidor <<processor>> servidor <<processor>> servidor <<network>> red local <<processor>> servidor de caché <<processor>> servidor de caché nodo conexión internet Modem nodo Diagrama de Despliegue • Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos.
    58. 58. Ing. Carlos Avalos Ruiz 58 Mecanismos comunes del modelo conceptual de UML • Especificaciones – Proporcionan una base semántica para cada elemento – Los diagramas son proyecciones de esa base • Adornos – La notación gráfica básica de cada elemento puede incluir adornos textuales o gráficos para resaltar algunas propiedades de la especificación.
    59. 59. Ing. Carlos Avalos Ruiz 59 • Divisiones Comunes – Dicotomía clasificador /instancia Persona nombre dirección teléfono Elena : Persona : Persona Elena • Divisiones Comunes – Dicotomía interfaz / implementación IOrtografía asistente Ortográfico.dll
    60. 60. Ing. Carlos Avalos Ruiz 60 Mecanismos de extension del modelo conceptual de UML • Mecanismos de extensibilidad – Estereotipos • Extienden el vocabulario de UML, permitiendo añadir nuevos tipos de bloques de construcción. – Valores etiquetados • Extienden las propiedades de un bloque de construcción, añadiendo nueva información.
    61. 61. Ing. Carlos Avalos Ruiz 61 – Restricciones • Extiende la semántica de un bloque, añadiendo reglas o modificando las existentes. Overflow <<Exception>> ColaEventos {version 3.2; autor: jgm} añadir() quitar() vaciar() {ordenado} estereotipo valor etiquetado restricción
    62. 62. Ing. Carlos Avalos Ruiz 62 Sistema, modelo, vista, diagrama • Un sistema es aquello que se está desarrollando y para lo que se crean modelos. • Un subsistema es una parte de un sistema. • Un modelo es una abstracción de un sistema que ayuda a comprenderlo. • Una vista es una proyección de la estructura y organización de un modelo del sistema, centrada en algún aspecto. • Un diagrama es una representación de un conjunto de elementos.
    63. 63. Ing. Carlos Avalos Ruiz 63 Vistas UML en términos de Elementos Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso clases interfaces colaboraciones componentes nodosclases activas casos de uso
    64. 64. Ing. Carlos Avalos Ruiz 64 Vistas UML en términos de Diagramas Vista de Diseño Vista de Implementación Vista de Procesos Vista de Despliegue Vista de casos de uso Diagramas de clase Diagramas de interacción Diagramas de estado Diagramas de componentes Diagrama de interacción Diagramas de estado Diagramas de despliegue Diagrama de interacción Diagramas de estado Diagramas de casos de uso Diagramas de clase Diagramas de interacción Diagramas de estado
    65. 65. Ing. Carlos Avalos Ruiz 65 Ejemplo: Hola mundo! import Java.awt.Graphics; class HolaMundo extends java.applet.Applet { public void paint (Graphics g) { g.drawString (“¡Hola, Mundo!”,10,10); } } HolaMundo paint() g.drawString ("Hola, mundo”) Abstracción de clases para hola mundo
    66. 66. Ing. Carlos Avalos Ruiz 66 Applet HolaMundo paint () Graphics Object Compone nt Container Panel Applet HolaMun do ImageObserver Clase relacionadas Con Holamundo Jerarquía de la Herencia de Hola mundo
    67. 67. Ing. Carlos Avalos Ruiz 67 java lang awt Applet HolaMundo Organización de paquetes de Holamundo
    68. 68. Ing. Carlos Avalos Ruiz 68 :Thread :Toolkit target:HolaMundo:ComponentPeer run run handleExpose paint callbackLoop Mecanismo para dibujar de Holamundo
    69. 69. Ing. Carlos Avalos Ruiz 69 HolaMundo.class hello.java hello.html Componentes de Holamundo
    70. 70. Ing. Carlos Avalos Ruiz 70 Equipo base de desarrollo Pero UML no es suficiente Unified Modeling Language Development process
    71. 71. Ing. Carlos Avalos Ruiz 71 Proceso de Desarrollo de Software • Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. Proceso de desarrollo de software Requisitos del usuario Sistema software
    72. 72. Ing. Carlos Avalos Ruiz 72 Un Proceso Iterativo e Incremental • Un proceso de desarrollo de software debe tener una secuencia de hitos claramente articulados para ser eficaz, que proporcionen a los director y al resto del equipo del proyecto los criterios que necesitan para autorizar el paso de una fase a la siguiente dentro del ciclo del producto. • Un proceso iterativo es aquel que involucra la gestión de un flujo de ejecutables del sistema.
    73. 73. Ing. Carlos Avalos Ruiz 73 • Un proceso incremental es aquel que involucra la continua integración de la arquitectura del sistema para producir esos ejecutables, donde cada nuevo ejecutable incorpora mejoras incrementales sobre los otros. • En conjunto, un proceso iterativo e incremental esta dirigido por el riesgo, lo que significa que cada nueva versión se encarga de atacar y reducir los riesgos mas significativos para el éxito del proyecto.
    74. 74. Ing. Carlos Avalos Ruiz 74 Lo que es una Iteración • Una iteración es un miniproyecto (un recorrido mas o menos completo a lo largo de todos los flujos de trabajo fundamenta) que obtiene como resultado una versión interna. • El resultado de una iteración es un incremento ( un in cremento es la diferencia entre la versión interna de una iteración y la versión interna de la siguiente). • Los modelos evolucionan con las iteraciones ( construyen los modelos incremento por incremento).
    75. 75. Ing. Carlos Avalos Ruiz 75 Las Iteraciones sobre el ciclo de vida • Las iteraciones se realizan en cuatro fases. • Cada una de las cuatro fases termina con un hito principal. – Inicio: Objetivos del ciclo de vida. – Elaboración: arquitectura del ciclo de vida. – Construcción: Funcionalidad operativa inicial. – Transición : versión del producto
    76. 76. Ing. Carlos Avalos Ruiz 76
    77. 77. Ing. Carlos Avalos Ruiz 77 ¿Por qué un Desarrollo Iterativo e Incremental? • Para tomar la rienda de los riesgos críticos y significativos desde el principio. • Para poner en marcha una arquitectura que guíe el desarrollo del software. • Para proporcionar un marco de trabajo que gestione de mejor forma los inevitables cambios en los requisitos y en otros aspectos.
    78. 78. Ing. Carlos Avalos Ruiz 78 • Para construir el sistema a lo largo del tiempo en lugar en lugar de hacerlo de una sola vez cerca del final, cuando el cambiar algo se ha vuelto costoso. • Para proporcionar un proceso de desarrollo a través del cual el personal pueda trabajar de manera mas eficaz. En resumen: “para obtener un software mejor”
    79. 79. Ing. Carlos Avalos Ruiz 79 Fases del Ciclo de vida time Inicio Elaboración Construcción Transición • Inicial: define el alcance del proyecto y el límite del sistema. • Elaboración: Plan del proyecto, características, y la línea base de la arquitectura. • Construcción: Se construye el producto • Transición: entrega del producto al usuario
    80. 80. Ing. Carlos Avalos Ruiz 80 Fases e Iteraciones Una fase es el intervalo de tiempo entre dos hitos importantes del proceso. Una iteración es una sucesión de actividades con un plan establecido y criterio de evaluación, mientras se va produciendo las versiones del sistema. Arch Iteration ... Dev Iteration Dev Iteration ... Trans Iteration ... Release Release Release Release Release Release Release Release Prelim Iteration ... Inception Elaboration Construction TransitionElaboration Construction Transition
    81. 81. Ing. Carlos Avalos Ruiz 81 Creando el Proceso Unificado Functional testing Performance testing Requirements mgmt Conf. and change mgmt Business engineering Data engineering UI design Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1996-1997 Objectory Process 1.0-3.8 1987-1995 The Ericsson Approach The Rational Approach UML Unified Process Unified Software Development Process Iconix Unified Process Rationa Unified Process 5.5

    ×