Metodología de Desarrollo de Sistemas Aland Bravo Vecorena Universidad De Huánuco 2009

Agenda  Evolución del Desarrollo de Software  Modelos  Lenguaje de Modelado Unificado (UML 2.0) –13 Diagramas UML –Diagrama de Casos de Uso  Conclusiones  Bibliográfia

Evolución del Desarrollo de Software Tiempo Código Máquina – Desarrollo Binario 7F 3A 2D FF Pseudocodigo – Modelo Textual 3GL Assembler – Desarrollo Textual ADD 1 JMP 122 Modelamiento Visual Desarrollo Textual 3GL Desarrollo Orientado al Modelo Potencia Niveles de automatización de los Entregables de Software Desarrollo Orientado al Negocio

¿Dónde nos encontramos?

Ciclo de Vida del Desarrollo Orientado al Negocio Model the Business Define Requirements Analyze & Design Implement Test Deploy Manage Optimize Executive Application Support Architect Project Manager Tester Deployment Manager Developer Business Development Operations Manage change & assets Manage change & assets Prioritize Plan Manage Measure Optimize Iterate End User Operations Manager Analyst Govern

Arquitectura Orientada al Servicio  SOA es un enfoque de las TIC que construye procesos de negocios a partir de módulos de componentes reutilizables o “servicios” que son independientes de las aplicaciones y de las plataformas computacionales en los cuales se ejecutan.

¿Porqué los Ingenieros Construimos Modelos?  Todo se relaciona con entender sistemas complejos –Un modelo es una version reducida de un sistema que enfoca lo esencial y oscurece lo irrelevante  abstracción.  Para detectar errores y omisiones en requirementos y soluciones antes de comprometer recursos a la aplicación completa.  Para comunicarse con los stakeholders –Clientes, usuarios, implementadores, testeadores, documentarios, etc.  Para guiar la implementación –Para los Ingenieros Telemáticos/Software, esto tiene un especial significado.

Características de los Modelos  Abstracto –Da énfasis a aspectos importantes mientras oculta o elimina lo irrelevante  Entendible –Se expresa en una forma que está presta a ser entendida por los observadores  Preciso –Fielmente representa el sistema planeado  Predecible –Puede usarse para derivar conclusiones correctas sobre el sistema planeado  Barato –Mucho más barato para construir y estudiar que el sistema modelado

El Lenguaje de Modelado Unificado  UML es el lenguaje estándar para especificar, visualizar, construir y documentar todos los artefactos de un sistema de software.  Es en cierto modo una síntesis de las notaciones de Grady Booch, Jim Rumbaugh, Ivar Jacobson entre otros.  Actualmente se cuenta con la versión UML 2.0.

Los 13 Diagramas del UML 2.0  Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: –Diagrama de clases Diagrama de clasesDiagrama de clases –Diagrama de componentes Diagrama de componentesDiagrama de componentes –Diagrama de objetos Diagrama de objetosDiagrama de objetos –Diagrama de estructura compuesta (UML 2.0) Diagrama de estructura compuestaDiagrama de estructura compuesta –Diagrama de despliegue Diagrama de despliegueDiagrama de despliegue –Diagrama de paquetes Diagrama de paquetesDiagrama de paquetes  Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: –Diagrama de actividades Diagrama de actividadesDiagrama de actividades –Diagrama de casos de uso Diagrama de casos de usoDiagrama de casos de uso –Diagrama de estados Diagrama de estadosDiagrama de estados  Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: –Diagrama de secuencia Diagrama de secuenciaDiagrama de secuencia –Diagrama de colaboración Diagrama de colaboraciónDiagrama de colaboración –Diagrama de tiempos (UML 2.0) Diagrama de tiemposDiagrama de tiempos –Diagrama de vista de interacción (UML 2.0) Diagrama de vista de interacciónDiagrama de vista de interacción

Jerarquía de los Diagramas UML

Ventajas del UML  Usando UML con una Arquitectura Orientada a Servicios permite generar código de Estructura y Comportamiento a partir del propio modelo.  Rápido desarrollo.  Alta calidad.  Requiere el uso de herramientas. 0% Comportamiento Estructura Codigo a Mano % Codigo Generado 100% 90%

Diagrama de Clases: Especificando la Estructura  Describe los tipos de objetos en el sistema.  Existen 2 tipos de relaciones: –asociaciones –subtipos  Posee atributos y operaciones.  Podría representar una interfaz ó herencia.

Diagrama de Componentes: Especificando la Estructura  Representa la separación de un sistema de software en componentes físicos y muestra la dependencia entre ellas.  Se incluye en este diagrama las librerías, archivos de tablas, ejecutables y documentos.

Diagrama de Objetos: Especificando la Estructura  Es una fotografía de los objetos en un sistema en un instante determinado.  Es útil cuando las conexiones entre objetos es compleja.

Diagrama de Estructura Compuesta: Especificando la Estructura  Muestra la estructura interna, incluyendo puntos de interacción a otras partes del sistema.  Describe la forma en que las clases se pueden mostrar como elementos compuestos, exponiendo interfaces y conteniendo puertos y partes.

Diagrama de Despliegue: Especificando la Estructura  Muestra la relación física entre componentes de hardware y software.  Los elementos usados son: –Nodos –Componentes –Asociaciones

Diagrama de Paquetes: Especificando la Estructura  Muestra un grupo de clases y la dependencia entre ellas.  Es equivalente a un diagrama de clase que muestra solo paquetes y dependencias.

Diagrama de Actividad: Especificando Comportamiento  Representa los flujos de trabajo paso a paso del negocio y operaciones de los componentes de un sistema, orientado principalmente al procesamiento paralelo.  Es una variación del Diagrama de Estado, donde los “estados” representan operaciones y las transiciones representan las actividades que ocurren cuando se completa la operación.  En UML 2.0 soporta semánticas basadas en las Redes de Petri.

Diagrama de Casos de Uso: Especificando Comportamiento  Descripción de Alto Nivel de los Escenarios del Sistema

Diagrama de Estados: Especificando Comportamiento  Representan máquinas de Estados Finitos.  Describe todos los posibles estados de un objeto particular, y como cambian de estado con eventos que accionan al objeto.  Las Acciones son transiciones ininterrumpible.  Las Actividades son estados que pueden tomar tiempo en ser procesadas, y que pueden ser interrumpidas por un Evento.

Diagramas de Secuencia: Especificación Detallada del Comportamiento  Especificación de la iteración del Comportamiento entre objetos de un sistema.  De la Caja Negra a la Caja Gris dependiendo del nivel de detalle.  Muestra la iteración de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase.

Diagrama de Colaboración: Especificación Detallada del Comportamiento  Muestra interacciones alrededor de los roles.  Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común.

Diagrama de Tiempos: Especificación Detallada del Comportamiento  Son una representación especial de interacción que se enfoca en el tiempo de los mensajes enviados entre objetos.  Son generalmente utilizados en sistemas de tiempo real o en sistemas embebidos. sd Reader r : Reader t1 Reading Idle Uninitialized Initialize Read ReadDoneRead {d..d+0.5} {t1..t1+0.1} State Event Occurrence Constraint

Diagrama de Vista de Interacción: Especificación Detallada del Comportamiento  Muestran una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que puedan ser realizados entre ellos.  Son importantes para modelar los aspectos dinámicos de un sistema y para construir sistemas ejecutables a través de ingeniería hacia adelante e ingeniería inversa.  Pueden servir para visualizar, especificar, construir y documentar los aspectos dinámicos de una sociedad particular de objetos, o pueden ser usados para modelar un flujo particular de control de un caso de uso. sd ATM-transaction client:atm:dbase: insertCard CheckPin ref alt [chk= OK] [else] error(badPIN) DoTransaction ref Interaction Frame

Conclusiones  El método Orientado al Servicio ha madurado y está siendo usado en las aplicaciones industriales de gran escala. –Gran uso de herramientas de automatización. –Mejora significativa en la productibilidad y confiabilidad.  La “nueva generación” UML 2.0 está caracterizada por: –Escalabilidad a grandes sistemas de software. –Aumento de la precisión semántica y claridad conceptual.

Mayor Información / Referencias SOA Design and DevelopmentSOA Design and Development IBM’s WebSphere Reference ArchitectureIBM’s WebSphere Reference Architecture Business IntegrationBusiness Integration Information on IBM WebSphere SoftwareInformation on IBM WebSphere Software Information on IBM Rational SoftwareInformation on IBM Rational Software IBM, Web Services, and SOAIBM, Web Services, and SOA IBM and Model-Driven Architecture (MDA)IBM and Model-Driven Architecture (MDA) Business Performance ManagementBusiness Performance Management