Sie sind auf Seite 1von 14

Instituto Tecnológico de la Laguna

3.3 EL MÉTODO DE BOOCH.

3.3.1 Introducción.

Análisis y Diseño Orientado a Objetos

El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura de todos los detalles de un sistema de software complejo es necesario vistas múltiples. La Figura # 44 muestra los diferentes modelos que se han considerado relevantes, en el desarrollo de un proyecto orientado a objetos.

Modelo Dinámico

Modelo Estático

Modelo Lógico

Modelo Físico

Estructura de clases Estructura de Objetos Arquitectura de módulos Arquitectura de procesos
Estructura de clases
Estructura de Objetos
Arquitectura de módulos
Arquitectura de procesos

Figura # 44 Modelos del desarrollo Orientado a Objetos

El hecho de que esta notación sea detallada no significa que se deben utilizar todos sus aspectos en la totalidad de las ocasiones, de hecho, un subconjunto de ella es suficiente para expresar la semántica de un gran porcentaje de problemas de análisis y diseño. La notación utilizada es independiente del lenguaje seleccionado, es necesario tener en cuenta que algunos elementos de la notación no tienen equivalencia en determinados lenguajes de programación, por lo que se deben evitar para la implementación.

3.3.2 Modelos y vistas.

Son necesarias dos dimensiones para especificar la estructura y comportamiento de un sistema orientado a objetos:

Dimensión uno: Física / Lógica.

Dimensión dos: Estática / Dinámica.

Para cada dimensión se definen una serie de diagramas que denotan una vista de los modelos del sistema, éstos reflejan "toda la verdad" sobre sus clases, relaciones y otras entidades, y cada diagrama representa una proyección de estos modelos. En el estado estable, todos estos diagramas deben ser consistentes con el modelo y también consistentes entre ellos mismos.

Modelos lógicos contra modelos físicos.

Modelo lógico: Describe la existencia y significado de las abstracciones principales y los mecanismos que forman el espacio del problema o para definir la arquitectura del sistema.

Modelo físico: Describe la composición concreta en cuanto a hardware y software del contexto o implantación del sistema.

Paola Romero Guillén

62

Instituto Tecnológico de la Laguna

Modelos estáticos contra modelos dinámicos.

Análisis y Diseño Orientado a Objetos

Modelos estáticos: Están formados por los diagramas de:

Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visión lógica de un sistema, utilizados en la etapa de análisis.

Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa de diseño lógico de un sistema.

Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el diseño físico de un sistema.

Diagramas de procesos: Muestran la asignación de procesos a procesadores en el diseño físico de un sistema.

Modelos dinámicos: La semántica dinámica de un problema se expresa mediante los siguientes diagramas:

Diagrama de transición de estados: Muestra el comportamiento de cada instancia de una clase, los eventos que provocan una transición de un estado a otro y las acciones que resultan de este cambio de estado, por lo que, cada clase puede contar con este tipo de diagrama.

Diagramas de interacción: Muestra el orden temporal en que se suceden los mensajes en un conjunto de objetos que representan un escenario. Están en el mismo contexto que los diagramas de objetos.

3.3.3 Representación gráfica.

Diagramas de Clases

Un diagrama de clases es utilizado para mostrar la existencia de clases y sus relaciones en la visión lógica de un sistema. Los dos elementos esenciales de un diagrama de clases son: las clases y sus relaciones básicas.

Clases: La figura # 45 muestra el icono que se utiliza para representar una clase en un diagrama de clases. En ciertos diagramas de clases, es útil exponer algunos de los atributos y operaciones asociados con una clase:

Nombre Atributos Operaciones( ) a) Icono de una clase
Nombre
Atributos
Operaciones( )
a) Icono de una clase

Figura # 45

Atributos: denotan una parte de un objeto agregado, durante el diseño expresan una propiedad singular de la clase.

! Nombre del atributo solamente.

A

! Clase del atributo solamente.

:C

A:C

! Nombre y clase del atributo.

Paola Romero Guillén

63

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Operaciones: denotan algún servicio proporcionado por la clase, se distinguen de los atributos añadiendo paréntesis.

! N() Nombre de la operación solamente.

! R N(Argumento) Clase de retorno de la operación, nombre y parámetros formales (si los hay).

Relaciones de clase: representan una colaboración con otras clases de diversas maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Asociación

 
  Herencia

Herencia

  Posesión
 

Posesión

 
  Uso
 

Uso

 

Figura

#

46

Iconos

de

relaciones

Asociación: conecta dos clases y denota una conexión semántica, se etiquetan con expresiones sustantivas, denotando la naturaleza de la relación.

Herencia: denota una relación de generalización / especialización (una relación <<es un>>), y aparece como una asociación con una cabeza de flecha. La flecha apunta a la superclase, y el extremo opuesto de la asociación designa la subclase. La subclase hereda la estructura y comportamiento de su superclase. Las relaciones de herencia no pueden llevar indicaciones de cardinalidad.

Posesión: denota una relación todo / parte (relación <<tiene un>> o agregación), aparece como una asociación con un círculo relleno en el extremo que señala al agregado, la clase que esta en el otro extremo denota la parte cuyas instancias están contenidas por el objeto agregado.

Utilización: denota una relación cliente / servidor y aparece como una asociación con una circunferencia en el extremo que denota al cliente. En esta relación de alguna forma el cliente depende del servidor para que éste le proporcione determinados servicios.

Pildora Come 50 50 Pacman 1 1 Fruta 1 1 Come 1 1 Figura #
Pildora
Come
50
50
Pacman
1 1
Fruta
1 1 Come
1 1
Figura # 47 Diagrama de clases

La multiplicidad o cardinalidad: se aplica el adorno de la cardinalidad al extremo de destino de una asociación y denota el número de enlaces entre cada instancia de la clase origen y las instancias de la clase destino.

1

Exactamente uno.

N

Número ilimitado.

Paola Romero Guillén

64

Instituto Tecnológico de la Laguna

0

N

Cero o más.

1

N

Uno o más.

0

1

Cero o uno.

3

7

Rango específico.

7 Rango específico o número exacto.

1

3,

Tipos de clases:

A F
A
F

Abstracta

Amiga

S V
S
V

Estática

Figura # 48

Virtual

Análisis y Diseño Orientado a Objetos

Abstracta: es aquella clase la cual no puede tener instancias. Para representarla se señala el icono de clase con la letra (A), situada en el interior de un triangulo, en cualquier punto del interior del icono de clase. Estática: la designación de un objeto o función miembro de una clase (S). Virtual: la designación de una clase base compartida en una trama de herencias con forma de rombo(V). Amiga: la designación de una clase que concede a otra derechos de acceso a sus partes no publicas (F).

Pacman 1 1 Laberinto Posición : entero 1 1 1 1 1 1 1 1
Pacman
1 1
Laberinto
Posición : entero
1 1
1 1
1 1
1 1
1 1
1 1
Come
S S
n n
4 4
F F
Come
Pildora
4 4
Fantasma
n n
Pildora_m
A A
Pildora_N
n n

Figura # 49 Ejemplo de Propiedades

Paola Romero Guillén

65

Instituto Tecnológico de la Laguna

Diagramas de Objetos.

Análisis y Diseño Orientado a Objetos

Un diagrama de objetos se utiliza para mostrar la existencia de objetos y sus relaciones en el diseño lógico de un sistema. Los dos elementos esenciales de un diagrama de objetos son los objetos y sus relaciones.

Objetos: La Figura # 50 muestra el icono que se usa para representar un objeto en un diagrama de objetos. Al igual que en el diagrama de clases, también se pueden especificar algunos atributos del objeto.

Nombre Atributo Figura # 50 Icono de objeto.
Nombre
Atributo
Figura # 50 Icono de objeto.

Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros objetos, representados por el icono de la Figura # 51, un enlace es una instancia de una asociación, al igual que un objeto es una instancia de una clase.

Mensaje(parámetros)

objeto es una instancia de una clase. Mensaje(parámetros) Objeto/valor Rol [Llave] Restricción Figura # 51
Objeto/valor Rol [Llave] Restricción
Objeto/valor
Rol
[Llave]
Restricción

Figura # 51 Relaciones entre objeto.

Mensaje: la existencia de una asociación entre dos clases denota por tanto una vía de comunicación entre instancias de clases, por la que un objeto puede enviar mensajes a otro. Un objeto también puede enviarse un mensaje a sí mismo. Cualquier objeto que invoque la operación se conoce como cliente, cualquier objeto que suministre la operación se conoce como proveedor o servidor. Un enlace se puede adornar mediante una serie de mensajes. Cada mensaje consta de tres elementos.

D Un símbolo de sincronización que denota la dirección de la invocación.

M Una invocación de operación o despacho de evento.

S Opcionalmente, un número de secuencia.

La dirección del mensaje se indica mediante una línea dirigida que apunta al objeto servidor. La invocación de una operación es el tipo de mensaje más común. La sintaxis es la siguiente:

N() Solamente el nombre de la operación.

R N(argumentos)

Objeto de retorno, nombre y argumentos actuales de la

operación.

Paola Romero Guillén

66

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Papeles, claves y restricciones: denotan el propósito o carácter de la relación que asocia una clase con otra. Es útil declarar este papel en el enlace correspondiente entre dos objetos, ya que ayuda a explicar porque un objeto opera sobre otro.

Flujo de datos: los datos pueden fluir en la misma dirección que un mensaje o en dirección contraria. El mostrar explícitamente la dirección del flujo de datos ayuda a explicar la semántica de un escenario particular.

Sincronización (para objetos activos).

Objetos activos: son aquellos que incorporan su propio hilo de control.

Simple: simple paso de mensajes secuencial. simple paso de mensajes secuencial.

de control. Simple: simple paso de mensajes secuencial. Sincronización: Espera hasta que el servidor acepta el

Sincronización: Espera hasta que el servidor acepta el mensaje.

Contratiempo: Abandona el mensaje si el servidor no puede proporcionar el servicio de manera inmediata.

Fuera de tiempo: Es igual al anterior, solo que en este caso se espera una cierta cantidad de tiempo

Sincronización: El servidor pone en la cola el mensaje y el cliente continua sin esperar respuesta. El servidor pone en la cola el mensaje y el cliente continua sin esperar respuesta.

Figura # 52 Sincronización.

Visibilidad. (valor / referencia negro/blanco)

G
G

Global: El objeto proveedor es global al cliente.

P
P

Parámetro: El objeto proveedor es parametro de alguna operación

del cliente.

F
F

Campo: El objeto servidor es una parte del cliente.

L
L

Local: Objeto declarado de forma local en el ámbito del diagrama.

Paola Romero Guillén

Figura # 53 Visibilidad

67

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Pildora Posicion : entero = 150 Valor : entero = 5 Numero : entero =
Pildora
Posicion : entero = 150
Valor : entero = 5
Numero : entero = 50
50 50
Pacman
Come
Posicion : entero = 12
Puntos : entero = 200
Vida : entero = 3
Velocidad : entero = 20
1
Fruta
1 Come
Posicion : entero = 100
Valor : entero = 15
1 1

Figura # 54 Diagrama de objetos.

Diagramas de transición de estados.

Un diagrama de transición de estados se utiliza para mostrar el espacio de estados de una clase determinada, los eventos que provocan una transición de un estado a otro y las acciones que resultan de ese cambio de estado.

Puede representar una vista del modelo dinámico de una sola clase o de un sistema completo. Debido a que durante el análisis se utilizan para indicar el comportamiento dinámico del sistema.

Estados: el estado de un objeto representa los resultados acumulados de su comportamiento. Todo estado debe de tener un nombre y este debe ser único dentro de la clase que lo contiene. Es también útil exponer las acciones asociadas a un estado.

Transiciones entre estados: se le conoce como cambio de estado, un evento es algún suceso que puede causar un cambio en el estado de un objeto. Cada transición de estados conecta a dos estados, un estado puede tener una transición hacia si mismo.

Acción: denota típicamente la invocación de un método, el disparo de otro evento, o el inicio o parada de una actividad.

Evento: puede ser un nombre simbólico, una clase o el nombre de alguna operación. Un evento puede proporcionar operaciones que pueden recibir tales nombres y efectuar la acción adecuada.

Transiciones de estado condicionales: en esta tipo de transición, esta será disparada automáticamente solo en el caso de que la expresión se evalué como cierta. El orden de evaluación en transición de estado condicionales es importante. En todo diagrama de transición de estados debe haber exactamente un estado de partida por defecto, que se designa escribiendo una transición sin etiqueta al estado desde un icono especial, que aparece como un circulo relleno. Es menos frecuente describir un estado de parada.

Paola Romero Guillén

68

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

nombre evento / acción acciones a) icono de estado b) icono de transición de estado.
nombre
evento / acción
acciones
a) icono de estado
b) icono de transición de estado.

Figura # 55

inicio entry: Camina
inicio
entry: Camina
de transición de estado. Figura # 55 inicio entry: Camina [ Fantasma come pacman ] /

[ Fantasma come pacman ] / Pacman termina

entry: Camina [ Fantasma come pacman ] / Pacman termina Activo do: Come Pildora, Camina Come
entry: Camina [ Fantasma come pacman ] / Pacman termina Activo do: Come Pildora, Camina Come
Activo do: Come Pildora, Camina
Activo
do: Come Pildora, Camina
Come Pildora_M En Borde do: Come Fantasma, incrementa velocidad do: Espera
Come Pildora_M
En Borde
do: Come Fantasma, incrementa velocidad
do: Espera

Figura # 56 Diagrama de transición de estados.

El diagrama de estados inicia cuando el Pacman camina, entra en un estado activo que tiene dos estados opcionales a donde puede irse. Si se topa en un borde entra en estado de espera y la otra opción es de comer Píldora-M en este estado puede comer fantasma e incrementar velocidad. El estado activo termina cuando un fantasma se come al Pacman.

Diagramas de interacción.

Es otra manera de representar el diagrama de objetos, tomando la mayoría de sus elementos esenciales de los diagramas de objeto. Con este tipo de diagramas es más fácil leer el paso de mensajes en orden relativo.

Paola Romero Guillén

69

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

: Pacman : Fruta : Pildora : Jugador Mover Camina_ Camina_Fruta(Posicion) Come_ Decrementa(n Come_
: Pacman
: Fruta
: Pildora
: Jugador
Mover
Camina_
Camina_Fruta(Posicion)
Come_
Decrementa(n
Come_

Figura # 57 Diagrama de interacción.

El diagrama de interacción esta compuesto de 3 bloques y un actor que es el jugador. Inicia con el mensaje mover que va del actor hacia la clase Pacman. Después la clase Pacman se envía un mensaje a el mismo que es el de caminar. Seguido de la clase Fruta donde su auto-mensaje es de camina_fruta. Después tanto Píldora como Fruta le envía un mensaje a Pacman de come, es decir estas pueden ser comibles por el Pacman.

Diagramas de módulos.

Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos a módulos en el diseño físico de un sistema. Un solo diagrama de módulos representa una vista de la estructura de módulos de un sistema. Los dos elementos esenciales de un diagrama de módulos son los módulos y sus dependencias.

Programa principal :Denota un archivo que contiene la raíz del programa.

Paola Romero Guillén

:Denota un archivo que contiene la raíz del programa. Paola Romero Guillén c) Programa Principal Figura

c) Programa Principal

Figura # 58

70

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Especificación y cuerpo: Denotan archivos que contienen la declaración y la definición de las entidades.

contienen la declaración y la definición de las entidades. a) Especificación en "C" archivo .h b
contienen la declaración y la definición de las entidades. a) Especificación en "C" archivo .h b

a) Especificación en "C" archivo .h

b) Cuerpo en "C" archivo .cpp

Figura # 59

Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Un subsistema es un agregado que contiene otros módulos y otros subsistemas. Cada modulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje.

nombre

d) Subsistema.

Figura # 60

Paola Romero Guillén

Sistema del Pacman

Definición de Pacman Definición de Pildora Definición de Fruta Definición de Campo Campo
Definición de Pacman
Definición de Pildora
Definición de Fruta
Definición de Campo
Campo

Sistema del Pacman

de Pildora Definición de Fruta Definición de Campo Campo Sistema del Pacman Figura # 61 Diagrama

Figura # 61 Diagrama de módulos

71

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Dependencias: la única relación que puede darse entre dos módulos es una dependencia de compilación, representada por una línea dirigida que apunta al modulo respecto al cual existe la dependencia. Las flechas denotan dependencias, la flecha sale del el icono dependiente.

Diagrama de procesos.

Se usa un diagrama de procesos para mostrar la asignación de procesos a procesadores en el diseño físico de un sistema. Un solo diagrama de procesos presenta una vista de la estructura de procesos de un sistema.

Elementos del diagrama

Procesadores. Elemento de hardware capaz de ejecutar programas.

Dispositivos. Elemento de hardware incapaz de ejecutar un programa.

Conexiones. Son líneas no dirigida para indicar conexiones entre procesadores y/o dispositivos.

nombre
nombre

a) icono de proceso

nombre
nombre

b) icono de dispositivo

c) icono de conexión

Figura # 62 Diagrama de Procesos. Estación de Juego del Usuario JoyStick
Figura # 62 Diagrama de Procesos.
Estación de Juego
del Usuario
JoyStick

Figura # 63 Diagrama de procesos, Representa el sistema del Pacman

3.3.4 El proceso.

El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunque esta bastante bien definido como para brindar un proceso predecible y repetible para una organización de software madura.

Un proyecto de software bien hecho es aquel en el que el software entregado satisface y posiblemente excede las expectativas del cliente. Se ha desarrollado de forma económica,

Paola Romero Guillén

72

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

entregado en tiempo, y es flexible al cambio y al crecimiento. En los proyectos que han tenido éxito se ha visto que existen los siguientes aspectos:

! La existencia de una fuerte visión arquitectónica. Un sistema con una buena arquitectura es aquel que cuenta con integridad conceptual, y las siguientes propiedades:

! Esta construido en capas de abstracción bien definida.

! Existe una separación entre la interfaz y la implementación de cada capa.

! La arquitectura es simple.

! La aplicación de un ciclo de vida bien dirigido, iterativo e incremental.

! Es iterativo ya que conduce al refinamiento sucesivo de una arquitectura orientada a objetos.

! Es incremental ya que en cada pasada por el ciclo; análisis / diseño / evolución conduce a un refinamiento gradual de las decisiones estratégicas y tácticas, convergiendo hacia los requerimientos reales y habitualmente no expresados por el usuario final.

El micro-proceso de desarrollo.

Esta dirigido por la corriente de escenarios y productos arquitectónicos, resultantes del macro- proceso y refinamientos sucesivos. El micro-proceso sigue las siguientes actividades:

Identifica clases y objetos a un nivel dado de abstracción:

Se identifican clases y tipos de objetos para delimitar el problema y tener bien establecido el dominio del mismo. A raíz de realizar esta etapa se crea un diccionario de datos donde se documentan dichos elementos, el cual servirá para tener una visión global del sistema.

Identifica la semántica de estas clases y objetos:

Se identifica que van a hacer y que representa cada clase de datos, por lo cual surge un refinamiento del diccionario de datos debido a que cada descripción de clase contendrá los atributos y responsabilidades de dichas clases.

Identifica las relaciones entre estas clases y objetos:

Se identifican las colaboraciones de cada clase u objeto, para establecer las asociaciones y se lleva a cabo mediante la descripción de las responsabilidades de cada abstracción. En esta etapa se especifican las asociaciones y mediante la separación de responsabilidades se lleva a cabo un refinamiento de las mismas, además esta etapa tiene como consecuencia otro refinamiento al diccionario de datos.

Especifica la interfaz y luego la implementación de estas clases y objetos:

En esta etapa se verifican las abstracciones existentes ya que se identifican la forma en que una abstracción responde al llamado de otra, lo cual lleva a definir métodos y mensajes transmitidos entre las abstracciones.

En la figura # 64 se muestra el micro-proceso de desarrollo.

Paola Romero Guillén

73

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Identificar clases

y objetos.

Diseño Orientado a Objetos Identificar clases y objetos. . Refinamiento del diccionario Diccionario de datos (clases

.

Refinamiento del

diccionario

clases y objetos. . Refinamiento del diccionario Diccionario de datos (clases y objetos) Especificar

Diccionario de datos (clases y objetos)

Especificar interfaces e implementación de clases y objetos.

interfaces e implementación de clases y objetos. Identificar semántica de clases y objetos . Identificar
Identificar semántica de clases y objetos .
Identificar semántica de clases y objetos .
Identificar semántica de clases y objetos .

Identificar semántica de clases y objetos.

Identificar semántica de clases y objetos .
Identificar semántica de clases y objetos .
Identificar relaciones entre clases y objetos.
Identificar relaciones entre clases y objetos.
Identificar relaciones entre clases y objetos.
Identificar relaciones entre clases y objetos.

Identificar relaciones entre clases y objetos.

Identificar relaciones entre clases y objetos.
y objetos . Identificar relaciones entre clases y objetos. Diccionario de datos (responsabilidades y accesibilidad

Diccionario de datos (responsabilidades y accesibilidad entre ellos)

Diccionario de datos (clases y objetos responsabilidades)

Figura # 64 Microproceso de desarrollo.

El micro-proceso se ve como un proceso de refinamiento dentro de las etapas del macro-proceso

Para cada una de las etapas se desarrollan los siguientes puntos:

Propósito.

Productos.

Actividades.

Hitos y medidas.

El macro-proceso de desarrollo.

En el marco de referencia para el control del micro-proceso, se dicta una serie de actividades cuantificables que permiten al equipo de desarrollo tasar el riego de forma significativa y realizar correcciones iniciales al micro-proceso de forma de centrar mejor las actividades de análisis y diseño del equipo. El macro-proceso realiza las siguientes actividades:

! Conceptualización: En esta etapa se establecen los requisitos esenciales para el sistema.

! Análisis: Se lleva a cabo un análisis en el dominio del problema para poder llegar a describir el problema basándose en el comportamiento del sistema.

! Diseño: Crear una arquitectura para la implementación.

! Evolución: En esta etapa se puede llegar a aumentar y cambiar la implantación mediante refinamientos sucesivos.

! Mantenimiento: Gestionar la evolución post-venta o post-entrega.

Para cada una de las etapas se desarrollan los siguientes puntos:

Propósito.

Productos.

Actividades.

Hitos y medidas.

Paola Romero Guillén

74

Instituto Tecnológico de la Laguna

Análisis y Diseño Orientado a Objetos

Gráficamente el macro-proceso se puede representar como en la figura # 65 .

Establecer

requisitos básicos

(conceptualización)

Desarrollar un

modelo del

comportamiento

deseado (análisis)

un modelo del comportamiento deseado (análisis) Crear una arquitectura (diseño) Gestionar la evolución
un modelo del comportamiento deseado (análisis) Crear una arquitectura (diseño) Gestionar la evolución

Crear una

arquitectura

(diseño)

deseado (análisis) Crear una arquitectura (diseño) Gestionar la evolución después de la entrega

Gestionar la evolución después de la entrega (mantenimiento)

Transformar la

implementación

(evolución)

Transformar la implementación (evolución) Figura # 65 Macro-proceso de desarrollo. Booch propone este
Transformar la implementación (evolución) Figura # 65 Macro-proceso de desarrollo. Booch propone este

Figura # 65 Macro-proceso de desarrollo.

Booch propone este proceso de desarrollo pensando en que el macro-proceso es aquel proceso donde las etapas de desarrollo abarcan un período grande, donde un equipo de desarrolladores se vera implicado, mientras que define al micro-proceso como una actividad diaria que se debe de realizar según lo que se va descubriendo o desarrollando durante el macro-proceso.

Mediante esta conceptualización durante las primeras etapas del macro-proceso en especial en el análisis es donde se estudia el comportamiento del sistema, se entra en el proceso del micro- proceso donde se describen que clases y objetos intervendrán, y mientras se avanza en el macro- proceso cuando se tengan establecidos los escenarios en el micro-proceso se podrá llevar acabo una narración de sucesos que ayudará a identificar las responsabilidades de cada abstracción.

Mediante el ejemplo anterior se percibe que durante una etapa dentro del macro-proceso se pueden tener varias iteraciones del micro-proceso, lo cual tendrá el propósito de refinar el sistema agregando o eliminando abstracciones que se presenten en el sistema.

No importa lo sofisticado que sea el método de desarrollo, y lo bien fundamentado que estén sus bases teóricas, no es posible ignorar los aspectos prácticos de diseño de sistemas para el mundo real. Esto implica que es necesario considerar buenas prácticas de gestión por lo que se refiere a temas como; administración de personal, gestión de versiones y control de calidad.

Paola Romero Guillén

75