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

Ingeniería de software II - Parte 3.1

on

  • 3,599 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,599
Views on SlideShare
3,599
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
  • 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