lunes, 13 de mayo de 2013

Análisis orientado a objetos (AOO) III. Caso práctivo de modelado CRC


Se trata de modelar un sistema de biblioteca con los siguientes requisitos:

Crear una aplicación para gestionar una biblioteca, la aplicación incluirá las búsquedas y préstamo de material bibliográfico, libros, revistas, documentos, etc.

Los socios podrán consultar el material bibliográfico.

Cada socio puede tener prestado un número máximo de elementos, 2 libros, 3 revistas y 4 documentos y cada tipo de material tiene un periodo de préstamo diferente. Libros 15 días, revistas 7 días, Documentos tres días.

Si se devuelve un elemento después de su fecha habrá una multa que también dependerá del tipo de objeto y de los días de demora.

Resolución

En nuestra búsqueda identificamos los nombres (Objetos) y los verbos (Responsabilidades)

Podemos crear la tarjeta CSocio que contendrá los datos del socio (nombre, dirección, teléfono, etc) con las responsabilidades de saber que elementos tiene prestados y por cuanto tiempo.

También parece obvia la tarjeta CMaterial que contendrá los datos del material (ISBN, Título, autor, etc ) y las responsabilidades de conocer las fechas de préstamo y devolución y la multa en caso de demora. Como estas responsabilidades dependerán del tipo de material se puede crear la tarjeta CLibro, CRevista y CDocumento como tarjetas hijas de CMaterial. Finalmente se puede crear un tarjeta que englobe todo CBiblioteca que tenga por funciones prestar y recibir material, visualizarlo, saber si está prestado o no.

El primer diagrama CRC podría ser de este estilo:

                      diagrama CRC

La clase CBiblioteca se conecta a la Base de Datos (esto puede requerir otra clase) para obtener y actualizar información relativa al material y a los préstamos. Dicha clase colabora con CSocio para obtener el material que presta o desea consultar el socio y con CMaterial para obtener la información relativa a este.

La clase CSocio contiene los datos del socio, del material que tiene prestado y las multas que se han aplicado al socio.

La clase CMaterial tiene información relativa a las fechas que presta el material y calcula las multas, de ella derivan tres clases específicas CLibro, CRevista y CDocumento que tienen la responsabilidad de calcular la multa correspondiente. Dicho cálculo es específico para cada tipo de material (polimorfismo), el resto de datos comunes se almacenan en la clase base CMaterial. Siguiendo estas tarjetas se valida y mejora el sistema de clases, creando nuevas clases responsabilidades y colaboraciones hasta llegar al diseño definitivo.

jueves, 9 de mayo de 2013

El modelo E/R y el diagrama de estructura de datos


El modelo E/R (Entidad/Relación)  se puede ver como una vista unificada de los datos, y adopta una organización más lógica de los datos consistente en Entidades y sus Relaciones.

Elementos del modelo E/R

El modelo de datos se compone de tres tipos de información relacionadas: el objeto de datos o Entidad, los atributos que describen la entidad y la relación que conecta las entidades entre sí.

Entidad

Una Entidad  es una representación de cualquier información que es procesada por el software.

Una entidad puede ser cualquier cosa que produce o consume información, una cosa (por  ejemplo, un informe o un teclado), un suceso (por ejemplo, una alarma), una unidad de la organización (por ejemplo, departamento de compras), o una estructura (por ejemplo, un archivo), una ocurrencia (por ejemplo, una salida del almacén), un puesto (por ejemplo, un operador de máquina).

Una persona, por ejemplo un paciente de un hospital se puede ver como una Entidad en el sentido en que se puede definir según un conjunto de atributos. La descripción de la entidad incorpora a la entidad todos sus atributos. (Nombre, DNI, domicilio, etc.)
Las entidades se relacionan con otras. Por ejemplo, un paciente puede tener una habitación, donde la relación tener implica una «conexión» específica entre paciente y habitación. Las relaciones siempre se definen por el contexto del problema que se está analizando.

Existen dos clases de entidades: regulares que son las que tienen una existencia por sí mismas, por ejemplo, Paciente, Hospital; y las débiles, en las que su existencia depende de otra entidad, por ejemplo, Familiar depende de Paciente, y la desaparición de los datos de un paciente de la BD lleva consigo el que desaparezcan también los datos de todos los familiares que estaban asociados al paciente.

En los esquemas se toma la convención de que las entidades regulares se representan mediante un rectángulo, mientras que para las débiles se utilizan dos rectángulos concéntricos.

Relación

Se denomina relación a la asociación entre entidades, y se representa mediante un rombo.

Las entidades se pueden conectar entre sí de muchas formas diferentes.  Por ejemplo dos entidades Tornillo y Almacén. Se establece una conexión entre tornillo y almacén porque los dos objetos se relacionan.  En función del contexto del software que se va construir. Podemos definir un conjunto de parejas entidad-relación que definen las relaciones relevantes. Por ejemplo:

Un almacén pide tornillos
Un almacén almacena tornillos
Un almacén vende tornillos
Un almacén devuelve tornillos

En la definición de relación existen los siguientes elementos:

Nombre: como cualquier objeto del modelo E/R, cada tipo de relación tiene un nombre que lo distingue unívocamente del resto y mediante el cual se referencia.

Grado: es el número de entidades que participan en una relación. Si una relación asocia dos tipos de entidad distintas (grado 2), como en el caso de la relación “Pertenece” entre Médico  y Especialidad. En el caso de que asocie sólo un tipo de entidad , se trata de una relación de grado 1 o reflexiva, esto sucede cuando por ejemplo si un médico es director de un departamento tenemos “director de” en la entidad Médico que al mismo tiempo uno de los médicos es director del resto.

Si encontramos una relación de grado n hay que tender a subdividirla en parejas de relaciones de grado 2 aunque dependiendo de la semántica del enunciado esto no siempre será posible y se deberá establecer una relación de grado 3, 4 o n.

Cardinales de las entidades: la cardinalidad se define como: El número máximo y mínimo de ocurrencias de un tipo de entidad que se pueden  relacionar con una ocurrencia del otro, u otros tipos de entidad que también participan en el tipo de relación.

Se representan gráficamente por una etiqueta del tipo (0,1), (1,1), (0,n) o (1,n) según corresponda. Por ejemplo, si a una especialidad pertenecen de 0 a n médicos, en la entidad Médico tendremos las cardinalidades (0,n); en otro sentido, también podemos suponer que un médico tiene que pertenecer obligatoriamente a una especialidad y como mucho a una (si no permitimos médicos con dos o más especialidades), por lo que las cardinalidades de Especialidad serán (1,1). Fig. 1

cardinalidad de las entidades


Si eliminamos la restricción y permitimos un médico con más de una especialidad en vez de (1,1) tendremos (1,n).

Tipo de correspondencia: es el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de relación que se está tratando. Se representa gráficamente como una etiqueta con 1:1, 1,N o N:M, según corresponda.

Si la correspondencia es N se dibuja una flecha hacia la entidad que tiene las N ocurrencias (Fig, 2), si es del tipo M:N se dibuja una flecha hacia cada entidad.(Fig. 3) 

tipo de correspondencia


Como se vio con las entidades, pueden ser regulares o débiles, en el caso de las relaciones si relacionan a dos entidades regulares será también regular, si una de las dos es débil, la relación también será débil. Dentro de las relaciones débiles aparece el concepto de Existencia cuando las ocurrencias de la entidad débil no pueden existir si desaparece la entidad regular de la que dependen.

Puede darse otro caso en el que una relación débil como la comentada anteriormente, no se puedan identificar las ocurrencias de la entidad débil de forma única a través de sus atributos propios lo cual obliga a añadir una clave perteneciente a la entidad regular (por ejemplo, si para identificar los ejemplares de un medicamento del almacén, utilizamos el código del producto y un contador, AAA01, AAA02 etc.) en ese caso lo llamamos dependencia de Identificación.

Una dependencia en la identificación es siempre una dependencia en existencia (pero no ocurre lo contrario).

Si la dependencia es en identificación, el rombo que representa la relación va etiquetado con “ID”, y con una “E” en caso de que la dependencia sea en existencia. Los datos sobre de los familiares de un paciente ingresado en un hospital sólo tienen sentido si dicho paciente permanece en la base de datos, aparece pues una dependencia en existencia.

Si las relaciones son exclusivas, se representa mediante un arco; como por ejemplo en la figura 3, en la cual se supone que si un médico es responsable de una especialidad no puede trabajar en otra especialidad.

relaciones exclusivas

Atributo

Cada propiedad o característica que tiene un tipo de entidad o un tipo de relación se llama Atributo. Los atributos toman los valores de un rango. Un atributo se representa gráficamente como un círculo u óvalo con su nombre.

Los atributos definen las propiedades de una entidad y se pueden usar para:

Nombrar una ocurrencia de la entidad
Describir la  ocurrencia,
Hacer referencias a otra ocurrencia en otra tabla.

Entre todos los atributos de una entidad hay que elegir uno o varios que identifiquen de forma unívoca cada una de las ocurrencias de dicha entidad. Este atributo o conjunto de atributos se llaman Atributo Identificador Principal (AIP), y lo representaremos por un círculo relleno.

Igual que las entidades, las relaciones también pueden tener atributos. Por ejemplo, la relación n:m Trabaja entre las entidades Médico y Odontología, tiene el atributo Función que especifica la función que tiene un médico en odontología, por ejemplo, ayudante. Fig, 4.

atributos

Generalización

Una necesidad habitual al modelar Bases de Datos es la descomposición de tipos de entidad en varios subtipos; en efecto, en el mundo real se identifican varias “jerarquías” de entidades. La relación que se establece entre un supertipo y sus subtipos corresponde a la noción de “Es-Un” (conocida por su s siglas inglesas “Is-a”) o más exactamente, “Es-un-tipo-de”.

Se representa utilizando un triángulo invertido, con la base paralela al rectángulo que representa el supertipo y se conecta a los subtipos como se muestra en la figura 5.  Las características de esta relación son las siguientes: cualquier ocurrencia de un subtipo es una ocurrencia del supertipo, aunque no sucede lo contrario, con lo que las cardinalidades serán siempre (1,1) en el supertipo y (0,1) o (1,1) en los subtipos.

Esta clase de relaciones tiene otra característica muy importante, es la herencia, pues todo atributo del supertipo pasa a ser un atributo de los subtipos; así, por ejemplo, se puede establecer una asociación de este tipo entre la entidad Médico y las entidades Investigador y Traumatólogo, en el sentido de que los investigadores y los traumatólogos “son” o “son tipos de” médicos, y, por tanto, heredarán todas las características de la entidad Médico (Código de personal, nombre, dirección, sueldo, etc.).
En las abstracciones de este tipo los atributos comunes a todos los subtipos (incluidos los identificadores) se asignan al supertipo, por otra parte los atributos específicos se deben asociar al subtipo que le corresponda. Además, las relaciones que afectan a todos los subtipos se asocian al supertipo, se asocian a los subtipos las relaciones específicas en las que participa el correspondiente subtipo –pero sólo dicho subtipo-; por ejemplo, en la figura 5 se considera que sólo los Traumatólogos están asociados a la entidad Paciente.

Fig. 5.


Generalización esquema E/R


Construcción de un esquema E/R

Se comienza por analizar la realidad  de lo que se desea plasmar en la base de datos, se analizan listados, pantallas, normativas, etc. 

Después se realiza un esquema, expresado en lenguaje natural, que nos facilite la creación de un esquema conceptual, por tanto es necesario “interpretar” las frases en el lenguaje natural en el que se ha descrito el esquema, luego las convertimos en elementos del modelo E/R, como pueden ser las entidades, atributos y las relaciones.

No existen reglas exactas que nos digan qué elemento va a ser una entidad o cual una relación, pero sí se pueden marcar unas normas generales y con un poco de buen criterio de diseñador, se puede elaborar un primer esquema conceptual:
           
-Un sustantivo (nombre común) que actúa como sujeto o complemento directo de una frase es, en general, una entidad, aunque también puede ser un atributo. Por ejemplo, en la frase “Los médicos atienden a pacientes”, existen dos posibles entidades: Médico y Paciente.

-Los nombres propios nos indican las ocurrencias de un tipo de entidad, Por ejemplo, “Félix” indica una ocurrencia de Paciente.

-Un verbo es una relación, en la frase anterior “atender” indica una relación entre las dos entidades, Médico y Paciente.

-Una preposición o una frase preposicional entre dos nombres suele ser un tipo de relación, o también puede establecer la asociación entre una entidad y sus atributos. Por ejemplo, al decir “la especialidad del médico”, estamos indicando la relación entre las entidades Especialidad y Médico, mientras que si decimos “la dirección del Médico”, estamos asociando el atributo Dirección a la entidad Médico.

preposiciones

Por tanto, simplemente basándonos en estos conceptos lingüísticos podemos generar un  esquema de conceptos preliminar.

Podemos construirlo desde un nivel alto de abstracción a uno bajo (descendente) o generar un esquema E/R en el papel y luego ir extendiéndolo y complicándolo (mancha de aceite).

Al finalizar el esquema, buscamos redundancias, ya que pueden derivar en problemas al implementar la base de datos. Es necesario buscar si existen atributos redundantes (los que se derivan de otros mediante algún cálculo, y que deben ser eliminados del esquema E/R, o bien etiquetados como redundantes), además hay que considerar la existencia de bucles en el diagrama E/R, ya que también pueden indicar la existencia de relaciones redundantes.


Como norma general, hay que tener en cuenta que la existencia de un bucle no implica la existencia de relaciones redundantes. Pero es necesario estudiar con mucho detenimiento las cardinalidades mínimas de las entidades y la semántica que aporten las relaciones. Si al eliminar una relación es siempre posible el paso en un sentido como en el inverso, entre las dos entidades unidas por la relación entonces existen relaciones redundantes.

Ejemplo sencillo

En la construcción de un sistema de información para el control hospitalario se revelaron los siguientes conceptos:

- Hospital: con los datos Nombre, Dirección y Teléfono

- Sala con los datos: número y cantidad de camas

- Médico, con los datos: Identidad, Nombre y Especialidad

- Paciente, con los datos: Identidad, Nombre, Dirección y Fecha de nacimiento.

Por otra parte, las relaciones reveladas entre dichos conceptos son:

-Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y sólo a uno).

-Cada médico trabaja en un único hospital, todo hospital tiene al menos 10 médicos.

-Un paciente puede estar internado; si lo está, estará en una sala y sólo en una.

-La capacidad máxima de camas que puede tener una sala es de cinco pacientes.

-Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno) y a su vez un médico puede atender a varios pacientes.

1º Definimos las entidades, para ello ponemos en rojo y negrita los sustantivos y nombres.

Con lo que obtenemos los siguientes candidatos a Entidad: Hospital, Sala, Médico, Paciente, Cama

2º Definimos las candidatas a relaciones, marcando los verbos en azul e itálica.

3º Marcamos en verde subrayado las preposiciones para asignar los atributos o identificar nuevas relaciones

Por lo que tenemos posibles relaciones: Hospital tiene salas, Hospital tiene Médicos, Médico trabaja en Hospital, Paciente está internado, en sala.
Paciente atendido por médico.

Y los siguientes atributos:

Hospital: Nombre, Dirección, Teléfono.
Sala: Número, Cantidad de camas.
Médico: Identidad, Nombre, Especialidad
Paciente: Identidad, Nombre, Dirección, Fecha Nacimiento
Cama:

4º Con estos datos montamos un esquema preliminar

Esquema preliminar modelo E/R


5º Buscamos redundancias, en este caso hay dos evidentes, Médico y Paciente

Con lo que quitándolas queda del siguiente modo:

modelo E/R

6º Si el esquema es cíclico es posible que haya relaciones redundantes, En nuestro caso es posible que la relación ”Está Ingresado”  sea redundante con la Interrelación “Atiende”, pues todos los pacientes atendidos están ingresados. (Aunque esto no sea así en la realidad, pues en un hospital se atiende a pacientes externos e ingresados, nos ceñimos al enunciado original donde no dice que haya pacientes externos) En principio no vamos a quitar dicha relación, pero hay que ponerla en “Cuarentena”.

7º Buscamos las cardinalidades

Para la cardinalidad Hospital-Médico tenemos el enunciado
-Cada médico trabaja en un único hospital, todo hospital tiene al menos 10 médicos.
Con lo que tenemos:
diagrama E/R


Para la cardinalidad Hospital-Sala tenemos el enunciado:



-Cada hospital tiene varias salas. Todas y cada una de ellas pertenecen a un hospital (y sólo a uno).
diagrama de estructura de datos


Para la cardinalidad Paciente-Sala (aunque es posible que se elimine en el futuro) tendríamos:

-Un paciente puede estar internado; si lo está, estará en una sala y sólo en una.
 Además
-La capacidad máxima de camas que puede tener una sala es de cinco pacientes.

diagrama de estructura de datos E/R



Finalmente para la cardinalidad Médico-Paciente tenemos el enunciado:

-Cada paciente puede ser atendido por más de un médico (pero por lo menos por uno) y a su vez un médico puede atender a varios pacientes.
médico -atiende- paciente


Y colocando el tipo de correspondencia, tenemos el siguiente Esquema preliminar, (teniendo en cuenta que la relación “Está Ingresado” podría ser redundante, aunque de momento no se quitará)

diagrama E/R hospital







lunes, 6 de mayo de 2013

Análisis orientado a orientado a objetos (AOO) II

El proceso de AOO


Para comenzar a analizar un proyecto no comenzaremos intentando ver que objetos tendrá la aplicación sino más bien si interaccionará con personas o con máquinas, como será esta interacción, si pertenece a un conjunto más amplio de programas o si se coordinará con otras aplicaciones. A continuación se exponen una serie de técnicas para recopilar datos para definir un modelo de análisis.

Casos de uso


Es una visión del sistema desde el punto de vista del usuario define el sistema con un escenario de uso habitual de interacción del sistema con el usuario final. Esta visión debe quedar definida de forma clara y sin ambigüedades y será un excelente modelo de creación de requisitos y de validación de pruebas. El resultado final es un diagrama de casos de uso de UML que puede representarse en diferentes niveles de abstracción.

lunes, 29 de abril de 2013

Análisis orientado a objetos (AOO).

Introducción


El objetivo del Análisis Orientado a Objetos (AOO) es desarrollar un modelo que describa el software de computadora necesario para satisfacer los requisitos definidos por el cliente. El modelo de análisis contiene el funcionamiento y el comportamiento de los elementos del modelo de objetos.

Nadie tiene muy claro por qué el Análisis Orientado a Objetos ha tardado tanto tiempo en ser aplicado a pesar de que maneja conceptos que aprendimos en la guardería como objeto, clase, miembro etc. No existe un acuerdo sobre los conceptos que sirven de base para el AOO, aunque se repiten a menudo un número de ideas clave.

El propósito es definir todas las clases, atributos, operaciones y relaciones de comportamiento asociado entre ellos que sean relevantes al problema que se va a resolver. Para realizar dicho análisis se deben ejecutar las siguientes tareas:

-Identificar los escenarios o casos de uso.


-Identificar las clases,


-Definir sus atributos y métodos.


-Especificar la jerarquía entre las clases.


-Representar las relaciones entre los diferentes objetos del sistema.


-Modelar el comportamiento de cada objeto.


-Repetir iterativamente las tareas anteriores hasta completar el modelo.

UML


Existían varios métodos para realizar AOO pero esos métodos se recombinaron en uno sólo llamado UML (Lenguaje de Modelo Unificado) este sistema aúna todos los procesos comunes y trata de tomar de cada método lo mejor. UML se caracteriza por cinco vistas independientes de un mismo problema, cada vista contiene un enfoque diferente del problema y lo muestra con gráficos de diferentes tipos.

Las cinco visiones diferentes de UML son:

Vista del usuario: representa el sistema desde la perspectiva de los usuarios (llamados actores en UML). Para este tipo de vista se utiliza el diagrama de casos de uso.


Vista estructural: modela la estructura estática (clases, objetos y sus relaciones).

Vista del comportamiento: representa los aspectos dinámicos o de comportamiento del sistema. También muestra las interacciones o colaboraciones entre los diversos elementos estructurales descritos en las vistas anteriores.

Vista de implementación: aquí se representan tal y como van a ser implementados los aspectos estructurales y de comportamiento.

Vista del entorno: muestra como irán los módulos implementados dentro del proyecto físico y las relaciones entre los diferentes módulos.

El AOO se centra en las vistas del usuario y estructural.

El DOO (modelo de diseño Orientado a Objetos) se centra más en las vistas del comportamiento y entorno.

Análisis del dominio


Es la primera actividad técnica a la hora de comenzar un nuevo proyecto. El objetivo de este análisis es definir las clases y objetos que están presentes en el dominio del problema propuesto. Esto dependerá del tipo de enfoque que se dé al problema o del área de negocio que se desea modelizar y se encuentra encuadrado dentro de un nivel medio de abstracción. Sirve para crear una biblioteca de clases que posteriormente podrán ser reutilizables (componentes).


Para ello cuando se diseñan las clases hay que tener en mente que no se realizarán con el único objetivo de integrarlas en una aplicación concreta, sino que deben diseñarse pensando en una posterior reutilización, esto es lo que llamamos análisis del dominio.

Por tanto se trata de identificar los requisitos comunes de una aplicación específica con vistas a su reutilización posterior dentro de un dominio de aplicación específico.

Un analista de dominio debe verse a sí mismo como un diseñador de herramientas para que los demás trabajen con ellas.



Definir el dominio


Consiste en aislar el área del negocio, se extraen las especificaciones y diseños de código que ya existan, clases, interfaz gráfica y clases de acceso a bases de datos, bibliotecas comerciales, también políticas, procedimientos, estándares, guías etc. En definitiva todo lo relevante para el proyecto. Se clasifican los elementos definiendo categorías de elementos y la nomenclatura de cada una de ellas.

Se deben identificar los objetos candidatos, ver si dichos objetos son reutilizables o adaptarlos para que lo sean y definir qué porcentaje de la aplicación podrá construirse con estos objetos reutilizables.

Se trata de desarrollar un modelo de análisis para los objetos que posteriormente servirá como base para la construcción de los objetos del dominio y su reutilización.

Componentes genéricos


Se trata de desarrollar un modelo del mundo real, dejando los detalles para más adelante. Se distingue entre componentes estáticos (que no cambian durante la vida de la aplicación) y componentes dinámicos (que se centran en el control y dependen del tiempo y de los sucesos).

Vista estática de clases, las que persisten a lo largo de toda la vida de la aplicación.

Vista estática de atributos, para definir las clases anteriores.

Vista estática de relaciones, para definir las conexiones e interacciones entre los objetos anteriores.

Vista estática de comportamientos, consiste fundamentalmente en un modelo de casos de uso que define una secuencia de operaciones genérica.

Vista dinámica de comunicación, define la comunicación dinámica entre objetos definiendo los mensajes que producen transiciones de un estado a otro.

Vista dinámica de control y tiempos, describe el tipo y duración de los sucesos que provocan la transición de estados entre ellos.

jueves, 25 de abril de 2013

Gestión de proyectos de software

El marco de proceso común para POO

Para el desarrollo de proyectos en POO el marco que mejor se ajusta es el recursivo /paralelo, adaptado a este tipo de programación podríamos definir el proceso de la siguiente manera:

-Aislar las clases del problema y las conexiones más importantes entre ellas.
-Intentar determinar si el diseño se puede llevar a la práctica, para ello es útil hacer un pequeño esquema de clases.

-Extraer los objetos reutilizables para montar una biblioteca de clases. O reutilizarlos si ya existen.

-Modificar el prototipo basándose en lo que se ha aprendido al realizar el diseño y de la realimentación obtenida del propio cliente.

-Ensamblar el prototipo usando los objetos de la biblioteca y los que se hayan creado nuevos.

-Realizar pruebas y de nuevo realimentación.

Este modelo indicado también se puede aplicar a componentes independientes del proyecto, también es útil tratar de descomponer a su vez cada componente en nuevos componentes  independientes y reiterar este proceso en cada resultado obtenido (recursividad).
Si en algún momento se detecta un componente o subcomponente existente en una biblioteca, se utiliza y se para el proceso de descomposición. Una vez identificados todos los componentes, es fácil trabajar sobre ellos en paralelo  (cada programador con uno) de modo que el progreso es fácil de realizar y fácil de medir.

Hitos

Se pueden de finir hitos en el desarrollo del proyecto cuando se han completado las siguientes tareas:

Fase de análisis

- Todas las clases y la jerarquía de clases se han definido y revisado.
- Lo mismo para los atributos y operaciones de las clases.
- Idem para las relaciones entre las clases.
- Se ha revisado el modelo de comportamiento.
- Se han establecido las clases reutilizables.

Fase de Diseño

- Se han definido todos los subsistemas.
- Cada clase se ha asignado a un subsistema.
- Se han identificado las responsabilidades y colaboraciones.

Fase Programación

- La implementación en código de cada clase.
- La integración de cada clase de una biblioteca.

Fase Pruebas

- Se ha revisado el modelo.
- Se han diseñado y ejecutado  casos de pruebas para cada clase.
- Se ha diseñado y ejecutado casos de pruebas para el sistema en su conjunto.