• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Ingeniería de software II - Parte 3.1
 

Ingeniería de software II - Parte 3.1

on

  • 3,356 views

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

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

Statistics

Views

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

Actions

Likes
4
Downloads
0
Comments
1

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

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

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • es un muy buen material, muy completo, sencillo y comprensible
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • Parte 1.2.1Proceso de Desarrollo UnificadoFLUJOS 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, BarbaraHaleyWixom and David Tegarden. SystemsAnalysis and Designwith UML Version 2.0 - AnObjectOrientedApproach, SecondEdition. 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, SteeMcRobb, y Ray Farmer. Análisis y DiseñoOrientado a Objetos del Sistema, Usando UML. McGraw-Hill, 2006.
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Proceso UnificadoFlujo de Requisitos
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Proceso UnificadoFlujo de Requisitos
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Roles y ArtefactosFlujo de Requisitos – Dirigido por Casos de Uso
      Arquitecto
      Diseñador de Interfaces de Usuario
      Especificador de los Casos de Uso
      Analista del Sistema
      Responsable
      de
      Responsable
      de
      Responsable
      de
      Responsable
      de
      Descripción
      de la
      Arquitectura
      Prototipo de
      Interfaz de
      Usuario
      Glosario
      Actor
      Modelo
      de Casos
      de Uso
      Caso de Uso
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Proceso UnificadoFlujo de Requisitos – Dirigido por Casos de Uso
      Encontrar Actores y Casos de Uso
      Analista del Sistema
      Estructurar el Modelo de Casos de Uso
      Priorizar Casos de Uso
      Arquitecto
      Especificador de los Casos de Uso
      Detallar Casos de Uso
      Diseñador de Interfaces de Usuario
      Prototipos de las Interfaces de Usuario
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Proceso UnificadoFlujo de Análisis
      PRODUCTOS
      • Dcto. de visión refinado
      • Dcto. de evaluación del riesgo refinado
      • Modelo de requisitos No-funcionales
      • Modelo de casos de uso arquitectónicamente significativos (Diagramas de Actividades, Diagramas de Comunicación)
      • Modelo de Clases
      • Modelo de componentes
      • Esquema de la base de datos
      • Prototipos definitivos
      • Arquitectura ejecutable
      • Modelo de Pruebas
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Flujo de Análisis UP
      Ingeniero de
      Casos de Uso
      Analizar un
      Caso de Uso
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Productos del Análisis y sus Responsables
      Responsable de
      Arquitecto
      Responsable de
      Ingeniero de
      Casos de Uso
      Clase de
      Análisis
      Responsable de
      Ingeniero de
      Componentes
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Artefactos UP-Análisis
      Modelo de Análisis
      Clase de Análisis
      Realización de Caso de Uso
      Paquete de Análisis
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Modelo de Análisis: Diagramas
      Diagrama de
      Objetos
      Modelo de
      Casos de Uso
      Diagrama de
      Secuencia
      Diagrama
      de
      Clases
      Diagrama de
      Colaboración
      Diagrama de
      Actividades
      Diagrama de
      Estados
      Flujo de Análisis UP
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Modelo de Casos de Usovs. Modelo de Análisis
      Flujo de Análisis UP
      Tomado de la Referencia [3]
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Propiedades del Desarrollo de Software Orientado por Objetos (1)
      Abstracción
      Encapsulamiento
      Herencia
      Polimorfismo
      Reusabilidad
      Elementos de Modelo:
      Clases
      Objetos
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Propiedades del Desarrollo de Software Orientado por Objetos (2):Conceptos de Abstracción y Herencia
      Tomado de Systems Analysis and Design with UML Version 2.0 - An Object Oriented Approach, Second Edition
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Clases y Objetos (3)
      UML provee un conjunto de elementos de modelo que son definidos desde diferentes niveles de abstracción. Por ejemplo las CLASES y los OBJETOS son definidos desde el nivel de METAMODELO y sus instancias se especifican al nivel de MODELO, como se muestra en las Figuras.
      En el nivel del METAMODELO los elementos son abstractos, es decir sólo se definen sus propiedades y posibles operaciones.
      En el nivel de MODELO los elementos son instancias del meta elemento y toma un valor específico.
      Figura 1
      Figura 2
      Material Preparado por MARTA SILVIA TABARES B. UdeM
      Figuras tomadas del Unified Modeling Language: Infrastructure
    • Clases y Objetos (4)
      Una CLASE en la teoría OO es la representación abstracta de los OBJETOS del mundo real que tienen las mismas características y comportamiento.
      Clase
      Objetos
      (Instancia)
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • UML: Notación de la Clase (1)
      Valor etiquetado, o
      Restricción (constraint)
      Nombre de la
      clase
      estereotipo
      Compartimiento de identificación de la clase
      Compartimiento de definición de atributos
      Valor inicial
      Compartimiento de identificación de las operaciones
      Alcance de la
      operación (parámetros)
      visibilidad
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • UML: Notación de la Clase (2)
      Alcance de la Instancia
      Alcance de la Clase
      Alcance de la Clase:
      Se refiere a los atributos y operaciones que pertenecen a , o operan en, toda clase de objetos.
      Alcance de la Instancia:
      Se refiere a los atributos y operaciones que pertenecen a , o operan en, objetos específicos
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • UML: Notación de la Clase (3)Alcance que determina el acceso
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • UML: Notación de la Clase (4)Visibilidad de una Clase
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (1): Elementos de modelo
      Clases
      Relaciones de:
      Abstracción (Dependencia)
      Asociación
      Generalización
      Agregación
      Composición
      Interfaces
      InterfazRealización
      Realización
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (2): Relaciones entre clases
      ABSTRACCIÓN
      Una relación de abstracción es una relación que relaciona dos elementos o conjunto de elementos que representan el mismo concepto en diferente niveles de abstracción o desde puntos de vista diferentes. una Abstracción es una Dependencia en la cual hay a la correlación entre el proveedor y el cliente.
      Clase
      A
      Clase
      B
      <<nombre del estereotipo>>
      Clase Cliente
      (la que requiere de la
      clase proveedora)
      Clase Proveedora
      (la que provee a la
      clase cliente)
      Pueden ser otros tipos de elementos de modelo tales como paquetes, y casos de uso, entre otros, en diferentes niveles de abstracción.
      Asociación
      Una relación de asociación describe un conjunto de tuplas cuyos valores se refieren a tipos de instancias. Una relación de asociación entre instancias es llamada un link (vínculo)
      ASOCIACIÓN
      Estereotipo de la relación de Dependencia entre el objeto y la clase
      Link
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (3): Relaciones entre clases
      Formas básicas de
      usar la Relación de
      Asociación
      multiplicidad
      (1)
      Este tipo de asociaciones son usadas para reducir una asociación con multiplicidad n:m, (1) realizando una clase tipo asociación, o (2) especificando un objeto o un grupo de objetos del conjunto destino
      (2)
      qualifier
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (4): Relaciones entre clases
      Una generalización relaciona un clasificador específico con un clasificador más general, que a su vez es poseído por el clasificador específico (un clasificador es una clasificación de instancias de acuerdo a sus características).
      GENERALIZACIÓN
      Figura tomada del Unified Modeling Language: Superstructure
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (5): Relaciones entre clases
      Figuras tomadas del Unified Modeling Language: Superstructure
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (6): Relaciones entre clases
      Una agregación es un tipo especial de asociación en la cual los objetos son reunidos o configurados juntos para crear un objeto más complejo. Una agregación describe un grupo de objetos y como se relaciona con ellos. La agregación protege la integridad de un ensamble de objetos definiendo un punto solo del control, llamado el agregado, en el objeto que representa el ensamble.
      AGREGACIÓN
      La agregación compuesta (composición) es una forma fuerte de la agregación. Esta requiere que una parte de instancia sea incluida en al menos una composición a la vez. Si una composición es eliminada, todas sus partes son normalmente suprimidas con esta.
      COMPOSICIÓN
      Figura tomada del: Unified Modeling Language: Superstructure
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (7): Relaciones entre clases
      Asociación
      Los objetos son conscientes unos de los otros, entonces ellos pueden trabajar juntos
      Agregación
      Protege la integridad de la configuración
      Las Funciones son una sola unidad
      El control es a través de un objeto – la propagación es descendente
      Composición
      Una parte puede ser un miembro de una sola configuración. Es decir, la parte “no puede existir” fuera de la configuración de la composición.
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Diagrama de Clases (8): Ejemplo: Diagrama de Clases – Sistema Bancario
      Rel. Asociación
      Rel. Agregación
      Multiplicidad*
      Rel. Generalización
      TIPS : Las especializaciones tienen sentido si tienen atributos u operaciones diferentes a los que heredan de la clase padre. Recuerden que la herencia es una relación excluyente y cada hijo tiene su especialidad.
      * También se conoce como CARDINALIDAD
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Paquetes (1)
      Un paquete es un contenedor UML el cual es propietario de elementos de modelo.
      Es un mecanismo de propósito general para agrupar y organizar elementos de modelo (incluyendo otros paquetes) y diagramas en grupo.
      Se puede usar para:
      Proporcionar un espacio encapsulado y nombrado dentro del cual todos los nombres son únicos.
      Agrupar semánticamente elementos relacionados.
      Definir un “límite semántico” en el modelo.
      Proporcionar unidades para el trabajo en paralelo y administración de la configuración.
      Pueden contener: casos de uso, clases de análisis, etc.
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Paquetes (2): Banking Account Package
      Elementos de Modelo del Paquete
      Paquete
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Paquetes (3): Companies Package
      Multiplicidad
      Multiplicidad
      Roles
      Rel. Reflexiva
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Paquetes (4): Visibilidad
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Relaciones entre Paquetes (1)
      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
    • Relaciones entre Paquete (2): Ejemplos
      Ejemplo 1:
      Paquete Cliente
      Paquete Proveedor
      Ejemplo 2:
      Figura tomada del: Unified Modeling Language: Superstructure
      Material Preparado por MARTA SILVIA TABARES B. UdeM
    • Tareas
      Cuáles son los cinco (5) estereotipos que UML provee para trabajar con la relación de Dependencia de Uso (Usage Dependency).
      Cuáles son los cuatro (4) estereotipos que UML provee para trabajar con la relación de Dependencia de Abstracción (Abstraction Dependency).
      No olvide realizarla, toda tarea o ejercicio propuesto es EVALUABLE
      Material Preparado por MARTA SILVIA TABARES B. UdeM