• Save
Ingeniería de software II- Parte 3.2
Upcoming SlideShare
Loading in...5
×
 

Ingeniería de software II- Parte 3.2

on

  • 3,212 views

Material de estudio de Ingeniería de Software II - Universidad de Medellín - Colombia

Material de estudio de Ingeniería de Software II - Universidad de Medellín - Colombia

Statistics

Views

Total Views
3,212
Views on SlideShare
3,212
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Ingeniería de software II- Parte 3.2 Ingeniería de software II- Parte 3.2 Presentation Transcript

  • Parte 1.2.2Proceso de Desarrollo Unificado FLUJOS DE TRABAJO – UP - Flujo de Requisitos - Flujo de Análisis Material académico preparado por: Ph.D, Marta Silvia Tabares B. Fecha última actualización 4-Sep-2011
  • Ingeniería de Software II(mapa conceptual de tópicos de conocimiento) Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Bibliografía• Roger Pressman. Ingeniería del Software (6ª ED.). Mcgraw-hill / Interamericana.• Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.• Ivar Jacobson, Grady Booch, James Rumbaugh. El Proceso Unificado de Desarrollo de Software. Adisson Wesley. 2001.• Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd Edition). Addison-Wesley Object Technology Series. 2005.• OMG-UML. Unified Modeling Language: Superstructure. version 2.0, formal/05-07- 04. 2005.• Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Clases de Análisis• Debe presentar un conjunto de atributos de muy alto nivel.• Las operaciones especifican, en un alto nivel, los servicios claves que la clase debe ofrecer.• La información mínima que una clase de análisis debe tener es: – Nombre (obligatorio) – Atributos (nombre: obligatorio, tipo: opcional) – Operaciones (de muy alto nivel; parámetros y tipos de retorno solo se muestran donde el analista considere importante para entender el modelo) – Visibilidad (generalmente no se muestra) – Estereotipos (se pueden mostrar si ellos mejoran el modelo) – Tagged values (se pueden mostrar si ellos mejoran el modelo) Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Clases de Análisis: Reglas de Creación• De tres a cinco responsabilidades por clase: las clases deben ser lo más simples que se pueda es decir se deben limitar el número de responsabilidades que ellas pueden soportar (una responsabilidad es un servicio (contrato) que una clase ofrece a otras).• No hay clases solas: una clase colabora con otra para entregar beneficios al usuario.• Cuidado con clases muy pequeñas.• Cuidado con clases muy grandes.• Cuidado con la funcionalititis• Cuidado con las clases omnipotentes.• Evitar profundidad en los árboles de herencia. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Clases de Análisis: Identificación por el Método CRC• CRC: Clases, Responsabilidades, y Colaboradores.• Procedimiento CRC – Fase I: Reunir la información Ejemplo: – Fase II: Análisis de la Información Nombre de la Clase: BankAccount Responsabilidades: Colaboradores: Mantener el balance Bank Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Clases de AnálisisEstereotipo Ícono Semántica<<boundary>> Clase que media la interacción entre el sistema y su ambiente<<control>> Clase que encapsula comportamiento del la especificación del caso de uso <<entity>> Clase que se usa para modelar la persistencia de la información Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Clases de Análisis Ejemplo Flujo de Análisis UPMaterial Preparado por MARTA SILVIA TABARES B. UdeM
  • <<boundary>> Class: Clase de Interfaz• Este tipo de clase se utiliza para modelar la interacción entre el sistema y sus actores (usuarios y sistemas externos). La interacción significa que recibe y presenta información, así como peticiones hacia los actores.• Esta clase modela las partes del sistema que dependen de sus actores, lo cual implica que clarifican y reúnen los requisitos en los límites del sistema. Así, un cambio en la interfaz de usuario o en una interfaz de comunicaciones queda aislado en una o más clases de interfaz.• Cada comunicación entre un actor y un caso de uso en el modelo de casos de uso, debe ser activado como un objeto en el sistema. Dichos objetos son instancias de una clase <<boundary>>. Así es posible definir que tipo de clase <<boundary>> es indicada para saber qué actor representa. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • <<boundary>> Class: Clase de Interfaz• La clase existe en los límites del sistema y se comunica con actores externos.• Tipos de clases <<boundary>> – Interfaces de usuario: clases que sirven como interfaz (punto de contacto) entre el sistema y los humanos (Interfaces tipo GUI). – Interfaces del sistema: clases que sirven de interfaz con otros sistemas. – Interfaces con dispositivos: clases que sirven de interfaz con dispositivos externos tales como un sensor. La Clase Interfaz Solicitud de Productos (GUI) Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • <<entity>> class: Clase de Entidad• Modelan la INFORMACIÓN que posee una vida larga.• Modelan la información y el comportamiento asociado de algún fenómeno o concepto, como una Persona, un Objeto del mundo real, o un Suceso del mundo real.• Características: – Cruzan muchos casos de uso – Proporcionan y Aceptan Información de las clases <<boundary>> – Representan cosas claves gestionadas por el sistema (p.ej. Cliente).• Son PERSISTENTES.• Las clases <<entity>> expresan la estructura de datos lógica del sistema. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • <<entity>> class: Clase de Entidad• En el siguiente ejemplo, la clase de entidad, Producto, se utiliza para representar los productos que el vendedor gestiona. La clase de entidad se asocia con la clase de interfaz, Solicitud de Productos, por medio de la cual el usuario administra los productos. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • <<control>> Class: Clase de Control• Este tipo de clase representa Coordinación, Secuencia, Transacción, y Control de otros objetos y se usa con frecuencia para encapsular de un caso de uso.• Las instancias de las Clases Controladoras controlan el sistema que corresponde a uno o más casos de uso.• Los aspectos dinámicos del sistema se modelan en clases de control ya que ellos coordinan las acciones y los flujos de control básicos (CU) y delegan trabajo a otros (interfaces, entidades). Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • <<control>> Class: Clase de Control• En el siguiente ejemplo, Controlador de Inventario, acepta una Solicitud de Productos, para crear el inventario de los Productos a una fecha determinada. Más adelante, el controlador de inventario lleva a cabo actualizaciones del producto cuando se realice una venta. Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Realización de Casos de Uso (Análisis)• Una Realización de Casos de Uso es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases del análisis y de sus objetos del análisis en interacción [3]. Modelo de Casos de Uso Modelo de Análisis• Una Realización de Casos de Uso implica la identificación de un posible conjunto de clases, junto con un conocimiento de cómo podrían interactuar esas clases para ofrecer una funcionalidad del caso de uso [5]. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Realización de Casos de Uso (Análisis) El desarrollo de un modelo o elemento abstracto para pasar a otro modelo que esté más cerca de la ejecución se conoce como Realización. El conjunto de clases que participan en una realización se conoce como una Colaboración. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Realización de Casos de Uso: Colaboraciones• La colaboración Hacer Préstamo muestra los elementos que interactuarán cuando se ejecuten como software, de tal forma que consigan el resultado descrito en el caso de uso Hacer Préstamo. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Interacción del Análisis: DIAGRAMA DE COMUNICACIONES• Un diagrama de comunicaciones constituye una vista del detalle interno de una colaboración ya que muestra la interacción entre los objetos Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Interacción del Análisis: DIAGRAMA DE SECUENCIA (1) Envía Mensaje Recibe Mensaje Inicio de Ocurrencia de Ejecución Ocurrencia de EjecuciónUna línea de Vidarepresenta la formacomo un objeto Fin de Ocurrencia de Ejecucióninteractúa con otrosobjetos del sistema. Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Interacción del Análisis: DIAGRAMA DE SECUENCIA (2)Fragmentos de operatividad de una interacción El fragmento Alternative (denotado “alt”) modela estructuras if…then…else. El fragmento Loop incluye una serie de mensajes que están repetidos. El fragmento Option (denotado “opt”) modela estructuras switch. Una ocurrencia de interacción es una referencia a otro diagrama que tiene la palabra “ref” en la esquina izquierda arriba del marco, y tiene el nombre del diagrama referenciado que se muestra en el medio del marco Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Interacción del Análisis:DIAGRAMA DE SECUENCIA (3) Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Realización de Casos de Uso (Análisis): Relación entre diferentes diagramas <<trace>>Estructura:Diagrama de Clases Interacción: Material Preparado por MARTA SILVIA TABARES B. UdeM Flujo de Análisis UP Diagrama de Comunicación
  • Análisis de la Arquitectura• Qué es una arquitectura de Software? – Es una forma coherente de establecer los patrones y abstracciones para que los analistas y desarrolladores trabajen en una línea común hacia la implementación del sistema de información. – Una arquitectura sigue un patrón o un conjunto de patrones que proporcionan un marco de referencia para lograr la funcional requerida por el cliente, y otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información.• El análisis de la arquitectura se hace por medio de la identificación de paquetes del análisis, clases representativas, y requisitos no funcionales. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Análisis de la Arquitectura: Identificación de paquetes (1)• Los paquetes del análisis proporcionan un medio para organizar el modelo de análisis de acuerdo a los objetivos del sistema a desarrollar (descomposición por objetivos o subobjetivos funcionales del sistema).• Paquetes de Análisis: – Comúnmente, se agrupan los casos de uso o elementos de modelo (clases del dominio) que cumplen con un objetivo específico del sistema, o dan soporte a determinado proceso del negocio, o dan soporte a determinado actor del sistema. Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Análisis de la Arquitectura: Identificación de paquetes (2)• En el sistema de Biblioteca se han identificado tres paquetes de acuerdo a los objetivos del sistema: – Gestión de Compra de Material Bibliográfico. – Gestión de Catalogación del Material Bibliográfico. – Gestión de Préstamo del Material Bibliográfico Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Análisis de la Arquitectura: Identificación de paquetes (3)• Paquetes de Servicios: – Están constituidos por clases de análisis que contribuyen a un servicio determinado del sistema (clases relacionadas funcionalmente). Cada paquete de servicio podría ser identificado por cada uno de los servicios proporcionados clases relacionadas funcionalmente (responsabilidades CRC). – Por ejemplo, en el paquete de Gestionar Préstamos de Material Bibliográfico, podemos encontrar dos servicios: Préstamos y Multas. Flujo de Análisis UP Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Análisis de la Arquitectura: Identificación de paquetes (4)• Paquetes por capas del sistema: – Orientados hacia una arquitectura por capas operativas del sistema, es posible identificar tres tipos generales de paquetes (para análisis bajo el patrón Modelo-Vista- Control): • Paquetes de Presentación: Agrupa todas las clases tipo interfaz. • Paquetes de Control: Agrupa todas las clase de control o paquetes de servicio. • Paquetes de Almacenamiento o Base de Datos: Agrupa todos las clases tipo entidad como un modelo de clases para la implementación en bases de datos. Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Análisis de la Arquitectura: Identificación de paquetes (5) Capa de Presentación (Vista)Dependencia entre Paquetes Capa de Control (Control) Capa de Almacenamiento (Modelo) Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Paquetes: Visibilidad Material Preparado por MARTA SILVIA Flujo de Análisis UP TABARES B. UdeM
  • Relaciones entre Paquetes Un elemento en el paquete Cliente usa un elemento público del paquete Proveedor de alguna forma. El cliente depende del proveedor. Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos públicos al espacio nombrado del Cliente. Elementos públicos del espacio nombrado del Proveedor son adicionados como elementos privados al espacio nombrado del Cliente. Elementos públicos del paquete Proveedor son combinados con elementos paquete Cliente. <<trace>> normalmente representa el desarrollo histórico de un elemento en otro en una versión más desarrollada. Esto se da más en relaciones entre MODELOS que en relaciones entre elementos de modelo. Símbolo que identifica un MODELO Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Análisis de la Arquitectura: Dependencia entre paquetes• A partir de paquetes relativamente independientes, débilmente acoplados y con una cohesión internamente alta (como los paquetes por capas del sistema), el objetivo de hacer relaciones entre los paquetes es mantener la relación funcional entre los diferentes elementos de modelo y facilitar la mantenibilidad del sistema.• La dependencia se formaliza por medio de las relaciones de dependencia entre paquetes: <<use>>, <<import>>, <<access>>, y <<merge>>. Material Preparado por MARTA SILVIA TABARES B. UdeM
  • Arquitecturas de Software• Continuar el estudio de este capítulo con la presentación: ARQUITECTURAS DE SOFTWARE Material Preparado por MARTA SILVIA TABARES B. UdeM