A1262717108QhRXK

1
Tema 3.4 Métodos convencionales de
especificación y diseño Qué es un
método? Lección 3.4.1 Métodos estructurados 1.
Proceso de especificación y diseño 2. SSA 3.
SSD carta de estructura 4. SSD proceso de
diseño 5. Conclusiones Lección 3.4.2 Métodos
orientados a objetos 1. Breve historia de
UML 2. Herramientas de UML 3. El proceso
UML 4. De los casos de usos al diagrama de
clases 5. Diseño 4. Comparación con los métodos
estructurados
2
Concepto de método

• Método (concepción del mundo herramientas de
  representación) heurísticas reglas de
  transformación y verificación proceso de
  aplicación
• El PROCESO es fundamental.
• INGENI(o)ERIA

3
Métodos estructurados proceso

• ANALISIS
• SSA Structured System Analysis (De Marco)
• DISEÑO
• SSD Structured System Design (Constantine,
  Yourdon)

4
SSA proceso

• 1. Modelo físico actual
• Estudio del entorno actual
• Nombres y particiones que utiliza el usuario
• 2. Modelo lógico actual
• Derivar el equivalente lógico eliminar
  componente físicos
• Normalizar los datos (por ej. M.E-R)
• 3. Modelo lógico nuevo
• Cambios en el sistema actual
• 4. Modelo físico nuevo
• Qué se va a automatizar? Varias alternativas
• Estudio de viabilidad

5
SSA proceso

• Muy ligado al ciclo de vida de las fases.
• Estudio de viabilidad tardío.
• Dificultad de establecer un contrato en estadíos
  iniciales.
• Verificación y validación continua con el usuario

6
SSA ? SSD

• DFD ? CARTA DE ESTRUCTURA.
• Pasar del flujo de datos a una estructura de
  programa.
• Se obtiene un programa en el que los módulos
  representan los procesos del sistema.
• Orientación procedimental, arquitectura modular.

7
Carta de estructura

• Representa la estructura modular de un programa.
• Relación jerárquica entre módulos.
• No indica orden de ejecución
• Elementos
• Módulos y sus relaciones
• Transferencias entre módulos
• Detalles adicionales procedimentales, léxicos.

8
Transferencia de control
Transferencia de datos
Recibir muestra
Transferencia de datos y control
NumCliente, NumAnimal
NumCliente
NumAnimal
Conexiones patológicas
Comprobar animal
Comprobar cliente
Alta muestra
NumAnimal
NumCliente
Referencia a datos
Alta cliente
Alta animal
9
Tipos de módulos (I)

• Según el flujo de datos
• Aferentes transfiere información desde los
  módulos inferiores a los superiores.
• Eferentes transfiere información desde los
  módulos superiores a los inferiores.
• De transformación transforma datos.
• Coordinación Coordina y gestiona otros módulos
• Según su función
• Ejecutivos llaman a módulos subordinados y
  realizan las decisiones del sistema.
• Atómicos realizan trabajos concretos.

10
Tipos de módulos (II)

• Según las conexiones
• Mínimamente conectados transmisión de datos y
  control a través de parámetros. Un solo punto de
  entrada la módulo.
• Normalmente conectados varios puntos de entrada
  (baja cohesión)
• Patológicamente conectados transferencias de
  control al interior o datos globales.

11
Carta de estructura morfología
ANCHURA PROFUNDIDAD FAN-OUT (abanico de salida)
número de módulos subordinados a otro FAN-IN
(abanico de entrada) número de módulos que
llaman a un mismo subordinado
12
SSD proceso de diseño

1. Revisión y refinamiento del DFD
2. Determinar el tipo de flujo en el DFD
3. Convertir en una carta de estructura
4. Factorizar
5. Refinar con principios de diseño acoplamiento,
   cohesión
6. Optimizar

13
DFD ? CARTA E.

• Flujo de transformación
• Entrada-Proceso-Salida
• Flujo de transacción
• Entrada-Decisión-Activación de módulos

14
Métodos estructurados conclusiones

• Estructura modular basada en un paradigma de
  programación estructurado.
• Centrado en el procesamiento de información.
• Los objetos de datos aparecen dispersos a lo
  largo del procesamiento.

15
Historia de UML
2001 2000 1999 1998 Nov . 1997
UML 2.0 UML 1.4
UML 1.3 UML 1.2 UML aprobado por
el OMG
16
Qué es UML?

• UML Unified Modeling Language
• UML combina
• Modelado de Datos (Diagramas Entidad-Relación).
• Modelado de Flujo de Trabajo (Work flow).
• Modelado de Objetos.
• Modelado de Componentes.
• Es un lenguaje estándar OO para especificar,
  construir y documentar sistemas software.
• Se puede utilizar en todos los procesos.

17
Herramientas de UML

• Diagrama de clases y objetos (E)
• Diagrama de casos de uso (E)
• Diagramas de secuencia y colaboración (D)
• Diagramas de estados (D)
• Diagrama de actividades (D)
• Diagrama de componentes (E)
• Diagramas de despliegue (E)

18
Proceso de desarrollo recursivo-paralelo

• 1) Especificar para aislar las clases más
  importantes y sus conexiones.
• 2) Pequeño diseño para determinar cómo
  implementar las clases y sus conexiones.
• 3) Extraer clases reutilizables de una librería y
  construir un prototipo burdo.
• 4) Probar el prototipo para descubrir errores.
• 5) Evaluar el prototipo con el usuario.
• 6) Modificar la especificación con TODO lo
  aprendido.
• 7) Refinar el diseño para acomodar los cambios.
• 8) Diseñar e implementar las clases especiales
  (no disponibles en las bibliotecas).
• 9) Realizar un nuevo prototipo con clases de
  biblioteca y las nuevas clases creadas.
• 10) IR A 4.

19

• Iteratividad.
• Reutilización.
• DISEÑO y ESPECIFICACIÓN no son absolutamente
  independientes.

20
Proceso iterativo simplificado de modelado y
diseño

• 1. Identificación y delimitación del sistema
• 2. Modelado del sistema
• 3. Diseño e implementación del sistema

21
1. Identificación y delimitación del sistema

• 1.1. Actividad del sistema
• Uso del sistema Casos de uso.
• Operaciones del sistema Diagramas de secuencia.
• 1.2. Principales clases y sus relaciones

22
2. Modelado del sistema

• 2.1. Modelado (estático) de clases y relaciones
  Diagrama de clases y de objetos
• 2.2. Modelado del comportamiento externo de las
  clases Contratos y diagramas de colaboración
• 2.3. Modelado del comportamiento interno de las
  clases Diagramas de transición de estados

23
3. Diseño e implementación

• Tomar decisiones de diseño y determinar las
  transformaciones introducidas en los anteriores
  diagramas por estas decisiones.
• Implementación del diseño.

24
De los casos de uso al diagrama de clases

• Clases
• A partir de los sustantivos relevantes de los
  casos de uso y documentos del usuario
• Atributos
• Relaciones
• A partir de los verbos relevantes

25
Clases categorías
26
Clases sustantivos

• No hay correspondencia mecánica entre sustantivo
  y concepto.
• El lenguaje natural puede ser ambiguo.
• Ejemplo
• Este caso de uso comienza cuando un cliente llega
  a una caja de TPDV con productos que desea
  comprar.
• El cajero registra el código universal de
  producto (CUP) en cada producto. Si el producto
  se repite, el cajero también puede introducir la
  cantidad.

27
Relaciones entre clases
(Las relaciones más importantes en negrita)
28
Atributos

• De los casos de uso, especificaciones, catálogos,
  ... se pueden descubrir algunos atributos.
• El cajero registra el código universal de
  producto (CUP) en cada producto. Si el producto
  se repite, el cajero también puede introducir la
  cantidad.
• Otros se detectan en fases posteriores.

29
Diseño en UML

• Los mismos conceptos que en el modelado
• Se determina la arquitectura del software
• Se introducen las clases que serán necesarias
  para la implementación
• Clases contenedoras
• Clases especiales para implementar formularios,
  gestores de eventos, interfaces con bases de
  datos,...

30
M. Estructurados ?? M.O. ObjetosPreguntas
curiosas

• Cómo podemos caracterizar un sistema software
  para que se pueda someter a un proceso de
  Ingeniería del Software?
• Dónde empieza y acaba el sistema?
• Cuáles son los elementos relevantes ?
• Cómo se relacionan entre sí estos elementos?
• Cómo se comportan los elementos en el contexto
  del sistema?

31
Respuestas curiosas
32
M.E. Diagrama de contexto
DenegasiónSistemática
Garrafón
Clientela
Banco
Pub La Tahà (Ese peaso de SISTEMA)
otroPréstamo?
DeclarasiónDeDeudas
Güiski
Hasienda
Probebedores
NiUnDuro
RecaudasiónEjecutiva
33
M.O-O. Contexto de uso

• Delimitar a partir del uso
• Por personas, si el sistema es interactivo.
• Por máquinas, si el sistema controla procesos.
• Por otros programas, si el sistema coordina y
  controla aplicaciones.

ClienteColgao