04_PD_DS_DOO

Análisis y diseño orientado a objetos Programa desarrollado

Ciencias Exactas, Ingenierías y Tecnología | Ingeniería en Desarrollo de Software 1

CARRERA: Ingeniería en Desarrollo de Software

Cuatrimestre 04

Programa de la asignatura:

Análisis y diseño orientado a objetos

Clave: 160920413 / 150920413



Índice

I. INFORMACIÓN GENERAL DE LA ASIGNATURA .............................................. 6 a. Ficha de identificación ............................................................................................................. 6

b. Descripción ............................................................................................................................... 6

c. Fundamentación teórica de la asignatura ............................................................................ 7

d. Propósito ................................................................................................................................... 8

e. Competencia(s) a desarrollar ................................................................................................. 9

f. Temario ....................................................................................................................................... 9

g. Metodología de trabajo ......................................................................................................... 11

h. Evaluación ............................................................................................................................... 11

i. Fuentes de consulta ................................................................................................................ 12

UNIDAD 1. INTRODUCCIÓN AL ANÁLISIS ORIENTADO A OBJETOS .............. 13 Presentación de la unidad ......................................................................................................... 13

Propósito ...................................................................................................................................... 13

Competencia específica ............................................................................................................ 13

Actividad 1. Presentación .......................................................................................................... 13

1.1. Generalidades ..................................................................................................................... 14

1.1.1. Definición .......................................................................................................................... 15

1.1.2. Características ................................................................................................................. 17

1.1.3. Ventajas ............................................................................................................................ 19

Actividad 2. Características y ventajas de la programación OO ......................................... 20

1.2. Identificación y conceptos básicos de modelos orientados a objetos ........................ 20

1.2.1. Abstracción ....................................................................................................................... 22

1.2.2. Encapsulamiento ............................................................................................................. 22

1.2.3. Modularidad ...................................................................................................................... 23

1.2.4. Herencia ............................................................................................................................ 23

1.2.5. Polimorfismo ..................................................................................................................... 24

Actividad 3. Ejemplos de sistemas .......................................................................................... 25

1.3. Ciclo de vida del software y tipos de ciclos .................................................................... 25



1.3.1. Definición .......................................................................................................................... 25

1.3.2. Espiral ............................................................................................................................... 26

1.3.3. Cascada ............................................................................................................................ 27

1.3.4. Incremental ....................................................................................................................... 28

Actividad 4. Conceptos básicos de los modelos Orientados a objetos ............................. 29

Autoevaluación ........................................................................................................................... 29

Evidencia de aprendizaje. Mapa mental de los modelos orientados a objetos ................ 29

Cierre de la unidad ..................................................................................................................... 30

Para saber más ........................................................................................................................... 30

Fuentes de consulta ................................................................................................................... 31

UNIDAD 2. REQUERIMIENTOS PARA EL ANÁLISIS DEL DISEÑO ORIENTADO A OBJETOS .......................................................................................................... 32

Propósito ...................................................................................................................................... 32


Presentación de la unidad ......................................................................................................... 32

2.1. Levantamiento de requerimientos .................................................................................... 34

Actividad 1. Análisis y diseño en un programa orientado a objetos ................................... 36

2.2. Documentación para levantamientos y especificaciones ............................................. 36

2.2.1. Documentación ................................................................................................................ 37

2.2.2. Especificaciones .............................................................................................................. 38

2.3. Estándares de Especificación ........................................................................................... 38

2.3.1. Fases de la estandarización .......................................................................................... 39

2.3.2. Análisis de restricciones ................................................................................................. 40

Actividad 2. Requerimientos, fases y restricciones para diseñar un programa ................ 41

2.4. Modelos del desarrollo del software ................................................................................ 41

2.4.1. Ágiles ................................................................................................................................. 43

2.4.2. Predictivos ........................................................................................................................ 43

Actividad 3. Cuadro Comparativo de modelos ágiles y predictivos .................................... 45

Autoevaluación ........................................................................................................................... 46

Evidencia de aprendizaje. Requerimientos para diseñar un programa Orientado a

Objetos ......................................................................................................................................... 46





UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DE SISTEMAS ORIENTADOS A OBJETOS .............................................................. 48


Propósito ...................................................................................................................................... 50


3.1. Booch .................................................................................................................................... 51

3.1.1. Introducción ...................................................................................................................... 51

3.1.2. Modelos ............................................................................................................................. 52

3.2. OOSE ................................................................................................................................... 57

3.2.1. Introducción ...................................................................................................................... 58

3.2.2. Modelos ............................................................................................................................. 60

3.3. OMT ...................................................................................................................................... 63

3.3.1. Introducción ...................................................................................................................... 64

3.3.2. Modelos ............................................................................................................................. 65

Actividad 1. Metodología para la generación de sistemas OO ........................................... 67

3.4. UML....................................................................................................................................... 67

3.4.1. Introducción ...................................................................................................................... 68

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)....................................................... 70

Actividad 2. Cuadro comparativo de las diferentes metodologías ...................................... 71

Autoevaluación ........................................................................................................................... 72

Evidencia de aprendizaje. Cuadro comparativo de los métodos de modelado ................ 72


Para saber más ........................................................................................................................... 73


UNIDAD 4. DISEÑO ORIENTADO A OBJETOS CON UML (LENGUAJE UNIFICADO DE MODELADO) .............................................................................. 75


Propósito ...................................................................................................................................... 75




4.1. Representación de objetos y clases con UML ............................................................... 76

4.1.1. Representación de clases con UML ............................................................................. 76

4.1.2. Representación de objetos con UML ........................................................................... 77

Actividad 1. Representación de clases y objetos con UML ................................................. 78

4.2. Diagramas y documentación para el diseño del software con UML ........................... 79

4.2.1. Casos de uso ................................................................................................................... 80

4.2.2. Escenarios del caso de uso ........................................................................................... 85

4.2.3. Diagramas de actividades .............................................................................................. 86

4.2.4. Diagrama secuencial ...................................................................................................... 88

4.2.5. Diagrama de clase .......................................................................................................... 89

Actividad 2. Aplicación de diagramas ...................................................................................... 91

4.2.6. Diagrama de gráfico de estado ..................................................................................... 92

Actividad 3. Diseño de diagramas en UML ............................................................................ 93

Autoevaluación ........................................................................................................................... 94

Evidencia de aprendizaje. Diagramas UML ........................................................................... 94


Para saber más ........................................................................................................................... 95




I. Información general de la asignatura

a. Ficha de identificación

Nombre de la Ingeniería: Desarrollo de software

Nombre del curso o asignatura: Análisis y diseño orientado a objetos

Clave de asignatura: 160920413 / 150920413

Seriación: No aplica

Cuatrimestre: Cuarto

Horas contempladas: 72 horas

b. Descripción

El hecho de pensar cómo o por dónde empezar a analizar los datos para diseñar un

programa de computadora es una labor complicada, más aun si el programa que se

quiere realizar está pensado en la metodología con orientación a objetos, la cual data de

los años cincuenta y no se usaba hasta hace poco porque la tecnología no estaba acorde

con su implementación. Hoy en día, la tecnología orientada a objetos se aplica desde que

se hace el análisis de un problema y sobre todo en el diseño de un programa que luego

será pasado a código en un lenguaje específico para dar solución a la necesidad de

automatizar la información de la empresa.

Los conceptos de análisis y diseño orientado a objetos surgen a partir de los lenguajes

modernos de programación. Aprovechando los beneficios de trabajar bajo este enfoque,

si se hace un buen análisis y diseño previo, el proceso de programación se vuelve fácil de

desarrollar y se obtienen mejores resultados.

En el análisis orientado a objetos se desarrollan una serie de modelos que nos orientan

sobre el software o lenguaje de programación a trabajar y así satisfacer un conjunto de

requisitos definidos por el cliente. El modelo del análisis orientado a objetos ilustra la

información, el funcionamiento y el comportamiento que llevará el flujo de la información

desde que se introduce, hasta lo que la computadora va a arrojar como resultado,

transformando el análisis de los datos en un modelo de diseño que sirve como

anteproyecto para la construcción de software, convirtiéndolo así incluso en un software

de fácil mantenimiento.



c. Fundamentación teórica de la asignatura

La asignatura de Análisis y diseño orientado a objetos tiene como función principal que se

aprenda a responder a las necesidades de flexibilidad en los sistemas de información,

mediante el manejo de los conceptos básicos de los modelos orientados a objetos tales

como herencia, polimorfismo, abstracción, etc. Dichos modelos han sido desarrollados

para que los sistemas sean más flexibles y el mantenimiento se vuelva sencillo. Mientras

que el desarrollo orientado a objeto involucra una fase de análisis y diseño más amplia,

esta inversión se traduce en menores costos de mantenimiento.

Existen varias metodologías orientadas a objetos; a pesar de que tienen variantes entre

ellas, todas trabajan con el mismo paradigma, por tanto se basan en los mismos

fundamentos. Las técnicas para el análisis y diseño Orientadas a Objetos todavía están

en desarrollo, esto debido a que la programación misma aún se encuentra en esta etapa.

Han surgido tantas metodologías que tratan este modelo de programación, siendo una de

las más usadas UML (Lenguaje Unificado de Modelado) por ser más eficiente en este

enfoque. Por lo anterior, en esta asignatura es necesario abordar una parte introductoria

sobre esta metodología (unidad 1), donde se abarcan conceptos generales del análisis,

los modelos orientados a objetos y el ciclo de vida del software. Estos conceptos se

utilizarán para poder llegar a la unidad 2, en la que se elaboran los papeles de trabajo

para este tipo de análisis con orientación a objetos. Así pues las unidades 1 y 2 están

enfocadas al análisis, mientras que en las unidades 3 y 4 se abarca lo concerniente al

diseño orientado a objetos.

Desde el inicio de la primera unidad, el estudiante interactúa con las herramientas del aula

virtual, como foros y bases de datos. Posteriormente, se llevan a cabo trabajos, así como

también se presentan actividades de investigación que complementan los contenidos, lo

que permite ejercitar y presentar sus evidencias de aprendizaje de los temas vistos en

cada unidad.

El enfoque teórico metodológico en el cual se sustenta la asignatura es un enfoque mixto,

donde se considerarán los siguientes aspectos:

Criterio cuantitativo: número de aportaciones: mínimo 2/tema a discutir.

Criterio cualitativo a través de escalas:

o Excelente: 100

o Bien: 80

o Regular: 60

o Insuficiente: 50



d. Propósito

El propósito general de la asignatura es realizar los diagramas que se requieren usando

como base el análisis de un sistema con orientación a objetos mediante las herramientas

de un lenguaje gráfico -como UML (Lenguaje Unificado de Modelado)- para visualizar,

especificar, construir y documentar un sistema.

La asignatura de Análisis y diseño orientado a objetos forma parte del cuarto cuatrimestre

de la Ingeniería en Desarrollo de software. La materia sirve de apoyo para la asignatura

de Programación orientada a objetos, además servirá como base para las asignaturas de

Programación orientada a objetos II y III de posteriores cuatrimestres y tiene como

asignatura precedente a Fundamentos de programación.

El curso se encuentra conformado por cuatro unidades:

1. Introducción al análisis orientado a objetos

2. Requerimientos para el análisis del diseño orientado a objetos

3. Metodologías de diseño para la generación de sistemas orientados a objetos

4. Diseño orientado a objetos con UML (Lenguaje Unificado de Modelado)

En la unidad 1 se presenta una introducción al análisis orientado a objetos, desde su

definición y características, hasta las ventajas de hacer un buen análisis para lograr un

diseño orientado a objetos, así como los conceptos básicos de modelos orientados a

objetos y lo referente al ciclo de vida del software. La unidad 2 trata sobre los papeles de

trabajo para el análisis del diseño orientado a objetos, donde se revisa el levantamiento

de requerimientos, los estándares de especificación y los modelos del desarrollo de

software. En la unidad 3 se exponen las diferentes metodologías para el diseño de

sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /

Ingeniería de Software Orientado a Objetos), OMT (Object Modeling Technique / Técnica

de Modelado de Objetos) y UML (Unified Modeling Language / Lenguaje Unificado de

Modelado). Finalmente, en la unidad 4, se trabaja el diseño orientado a objetos con

diagramas UML, con el fin de tener un diagrama de fácil entendimiento que podrá ser

convertido en un diseño con orientación a objetos, logrando que sea fácil de codificar en

cualquier lenguaje con programación orientada a objetos.



e. Competencia(s) a desarrollar

Competencia general:

Diagramar la estructura de un sistema orientado a objetos para su diseño con base en el

análisis del sistema mediante el uso de UML (Lenguaje Unificado de Modelado).

Competencias específicas:

Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de

vida, utilizando los conceptos de orientación a objetos.

Distinguir los requerimientos del sistema orientado a objetos en su etapa de

análisis para definir su diseño mediante técnicas y estándares de especificación.

Comparar las metodologías de diseño para la generación de sistemas orientados a

objetos mediante los diagramas con los métodos de modelado Booch, OOSE,

OMTy UML.

Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos

mediante el método de modelado UML.

f. Temario

Unidad 1. Introducción al análisis orientado a objetos

1.1. Generalidades

1.1.1. Definición

1.1.2. Características

1.1.3. Ventajas

1.2. Identificación y conceptos básicos de modelos orientados a objetos

1.2.1. Abstracción

1.2.2. Encapsulamiento

1.2.3. Modularidad

1.2.4. Herencia

1.2.5. Polimorfismo

1.3. Ciclo de vida del software y tipos de ciclos

1.3.1. Definición

1.3.2. Espiral

1.3.3. Cascada

1.3.4. Incremental

Unidad 2. Requerimientos para el análisis del diseño orientado a objetos

2.1 . Levantamiento de requerimientos



2.1.1. Introducción a los requerimientos

2.1.2. Actividades para el levantamiento de requerimientos

2.2 . Documentación para levantamientos y especificaciones

2.2.1 Documentación

2.2.2 Especificaciones

2.3 . Estándares de especificación

2.3.1 Fases de la estandarización

2.3.2 Análisis de restricciones

2.4 . Modelos del desarrollo de software

2.4.1. Ágiles

2.4.2. Predictivos

Unidad 3. Metodologías de diseño para la generación de sistemas orientados a objetos

3.1. Booch

3.1.1. Introducción

3.1.2. Modelos

3.2. OOSE


3.2.2. Modelos

3.3. OMT


3.3.2. Modelos

3.4. UML


3.4.2. OCL (Lenguaje de Especificación de Objetos)

Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de Modelado)

4.1. Representación de objetos y clases con UML

4.1.1. Representación de clases con UML

4.1.2. Representación de objetos con UML

4.2. Diagramas y documentación para el diseño del software con UML

4.2.1. Casos de uso

4.2.2. Escenarios del caso de uso

4.2.3. Diagramas de actividades

4.2.4. Diagrama secuencial

4.2.5. Diagrama de clase

4.2.6. Diagrama de gráfico de estado



g. Metodología de trabajo

El aprendizaje basado en la resolución de problemas es una metodología en la que se

presentan situaciones diversas para que se lleve a cabo la aplicación de fórmulas,

algoritmos y procedimientos, así mismo rutinas que permitan ejercitar y poner en práctica

los conocimientos y procedimientos para promover el reforzamiento de lo aprendido o la

resolución de dudas, así como el aprendizaje significativo, al comprobar los elementos

teóricos.

Al aplicar este tipo de metodología en la asignatura, también se toman en cuenta:

El uso de las siguientes herramientas tecnológicas: a) un foro general al inicio de la

asignatura cuyo propósito es favorecer la comunicación y el conocimiento entre los

estudiantes, b) foros que sirven como base para participar en temas propuestos y

obtener un mayor conocimiento acerca de los temas de cada unidad.

La realización de actividades formativas, entre las que destacan: tareas en las que

se analiza el tema y se selecciona un ejemplo u otras en las que dado un ejemplo

especifico se pide entregar documentación a requerimientos, también elaborar

secuencias de tiempo investigaciones y diseñar diagramas como parte final para la

aplicación del conocimiento adquirido.

La construcción del portafolio de evidencias (e-portafolio), el cual consta de la

elaboración de mapas mentales para evidenciar el conocimiento adquirido,

levantamientos de requerimientos, cuadros sinópticos y diseño de diagramas con

problemas relativos a los temas abordados en cada una de las unidades que

integran la asignatura, que reflejen la utilización de los conocimientos adquiridos a lo

largo de ésta.

La realización de actividades de autoevaluación que den cuenta del grado de

aprendizaje adquirido y refuercen los conocimientos.

h. Evaluación

En el marco del Programa ESAD, la evaluación se conceptualiza como un proceso

participativo, sistemático y ordenado que inicia desde el momento en que el estudiante

ingresa al aula virtual, por lo que se le considera desde un enfoque integral y continuo.

Por lo anterior, para aprobar la asignatura, se espera la participación responsable y activa

del estudiante, así como una comunicación estrecha con su Facilitador(a) para que pueda

evaluar objetivamente su desempeño, para lo cual es necesaria la recolección de



evidencias que permitan apreciar el proceso de aprendizaje de contenidos: declarativos,

procedimentales y actitudinales.

En este contexto la evaluación es parte del proceso de aprendizaje, en el que la

retroalimentación permanente es fundamental para promover el aprendizaje significativo y

reconocer el esfuerzo. Es requisito indispensable la entrega oportuna de cada una de las

tareas, actividades y evidencias, así como la participación en foros y demás actividades

programadas en cada una de las unidades, y conforme a las indicaciones dadas. La

calificación se asignará de acuerdo con la rúbrica establecida para cada actividad, por lo

que es importante que el estudiante la revise antes de realizar las actividades.

A continuación presentamos el esquema general de evaluación.

ESQUEMA DE EVALUACIÓN

Evaluación

continua

Interacciones individuales y

colaborativas 10%

Tareas 30%

E-portafolio.

50%

Evidencias 40%

Autorreflexiones 10%

Examen 10%

CALIFICACIÓN

FINAL 100%

Cabe señalar que para aprobar la asignatura, se debe de obtener la calificación mínima

indicada por ESAD.

i. Fuentes de consulta

Bibliografía básica

Booch-Grady (1996). Análisis y Diseño Orientado a objetos con aplicaciones.

México: Pearson Educación.

Kendall, E. (2005). Análisis y Diseño de sistemas. México: Pearson Educación.

Seen, J. (1990). Análisis y Diseño de sistemas de Información. México: Mc Graw

Hill.

Bibliografía complementaria

Sommerville, I. (2005). Ingeniería del Software. México: Pearson Educación.



Unidad 1. Introducción al análisis orientado a objetos

Presentación de la unidad

Bienvenido(a) a la asignatura Análisis y diseño orientado a objetos. En esta primera

unidad se expondrán los principios fundamentales de un buen análisis para hacer un

correcto diseño y así poder programar con orientación a objetos, lo que permitirá dar

cumplimiento al propósito de la unidad.

En la primera parte de esta unidad te enfrentarás en la sección de análisis y diseño, con

algunos conceptos básicos como la definición, las características y las ventajas de hacer

un análisis previo de la información y deberás conocer, en la segunda parte de esta

unidad, los conceptos de orientación a objetos para que cuando hagas tu diseño sepas

darle ese enfoque, también distinguirás las características de este tipo de programación.

Finalmente, conocerás el ciclo de vida del software y algunos tipos de ciclos. Toda esta

información es el principio básico de un buen análisis de diseño orientado a objetos.

Propósito

Conocer los atributos de los modelos orientados a objetos para poder establecer las

necesidades del diseño de un sistema con estas características, así como ubicar las

etapas de vida del software.

Competencia específica

Identificar las etapas de un sistema orientado a objetos para decidir su ciclo de vida,

utilizando los conceptos de orientación a objetos.

Actividad 1. Presentación

Antes de entrar de lleno en el estudio de la asignatura, te presentamos un foro de

discusión general, el cual fue creado con la finalidad de que te presentes con tus

compañeros y comentes cualquier asunto relacionado con la asignatura; en él, conocerás

a tus compañeros de grupo y entre todos podrán apoyarse para resolver dudas,

inquietudes, externar comentarios, etcétera.



Para comenzar tu participación, ingresa al foro Presentación.

1.1. Generalidades

El objetivo principal del análisis orientado a objetos (AOO), es desarrollar un software

capaz de cubrir con las necesidades esenciales del usuario final, y su diseño se enfoca

en los objetos.

El análisis orientado a objetos y su diseño se basa en definir una serie de actividades

relevantes al problema que se va a resolver, en donde son comúnmente utilizadas las

operaciones y atributos asociados. Para cumplir con esto se deben tener en cuenta las

siguientes tareas:

1.- Debe de existir una comunicación sobre los requisitos básicos del usuario ya que

será el usuario final del software.

2.- Se deben definir los métodos a utilizar para el análisis.

3.- Se debe definir la jerarquía de los métodos utilizados para el análisis.

4.- Deben existir relaciones de objeto a objeto, así como todas sus conexiones.

5.- Debe modelarse el comportamiento del objeto.

Las actividades anteriores se aplican de forma iterativa hasta que el modelo esté

completo.

El software orientado a objetos es más fácil de mantener debido a que su estructura es

inherentemente poco acoplada. Además los sistemas orientados a objetos son más

fáciles de adaptar y escalables.

El enfoque realizado sobre el desarrollo orientado a objetos no debe implicar hacer las

tareas diferentes del enfoque clásico de desarrollo de software puesto que se

desarrollan actividades similares en un proceso evolutivo.

El modelo orientado a objetos tiene como característica el hecho de que un elemento

del mundo real se puede representar a través de sus características y de sus

comportamientos.

Los conceptos como clase, objeto, instancia, atributos y métodos, se hacen cotidianos

en el AOO, ya que son parte de su vocabulario.

Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmente

aplicables a sistemas desarrollados usando métodos orientados a objetos. Por esa



razón, un AOO debe exhibir abstracciones de datos y procedimientos que conducen a

una modularidad eficaz.

La gestión de un proyecto de software orientado a objetos por lo general tiene

actividades como:

1.- Establecer un proceso común para el proyecto.

2.- Usar métricas para desarrollar estimaciones de tiempo y esfuerzo.

3.- Especificar productos de trabajo e hitos que permitirán medir el progreso.

4.- Tener puntos de comprobación para la gestión de la calidad y control.

5.- Controlar cambios que se generan durante el progreso del proyecto.

6.- Realizar el seguimiento y control del progreso.

El AOO se basa en un conjunto de principios básicos comúnmente usados:

1.- Modelado de la información.

2.- Descripción de funciones.

3.- Representación del comportamiento del modelo.

4.- Desarrollo de modelos de datos, funcional y de comportamiento.

El análisis y desarrollo orientado a objetos puede ser interpretado como el conjunto de

disciplinas que desarrollan y modelan un software que facilita la construcción de

sistemas de información complejos a partir de la formación de sus componentes.

Las técnicas orientadas a objetos proporcionan mejoras y metodologías para construir

sistemas de software complejos a partir de unidades de software, el enfoque del AOO

debe ser capaz de manipular sistemas grandes y pequeños que sean flexibles con

facilidad de mantenimiento y capaces de evolucionar con respecto a las necesidades y

requerimientos del usuario final.

1.1.1. Definición

Para comenzar a entender en qué consiste el análisis y diseño de software orientado a

objetos, empezaremos por definir el término orientado a objetos, pero vayamos por

partes, como se muestra a continuación:

Objeto: Instancia de una clase específica. Los objetos heredan los atributos y

operaciones de una clase.

Clase: Representa a una entidad que tiene un estado interno y un comportamiento

característico.

Atributos: Son los datos a los que se refiere el estado del objeto (Booch-Grady, 1996).



Los objetos tienen un estado interno y un comportamiento, el estado de un

determinado objeto es un conjunto de parámetros con valores que lo caracterizan.

Estos parámetros son atributos y representan lo mismo que los campos de una tabla

de una base de datos o las variables de un programa estructurado, por ejemplo:

La edad de una persona

El nombre de un animal

La altura de un edificio

La jornada de un trabajo

El comportamiento de un objeto se forma por el conjunto de operaciones que se

pueden realizar. Cada una de esas operaciones recibe el nombre de método. Los

métodos podrían ser:

Dibujar un triángulo

Asignar laboratorio de trabajo a un grupo

Prestar un libro de la biblioteca

Cada objeto de una clase tiene sus propios atributos, que describen y caracterizan el

estado en cada momento, y un conjunto de métodos, sobre los cuales ejecuta las

operaciones que manifiesta su comportamiento.

El análisis orientado a objetos (AOO) construye un modelo orientado a objetos y a las

clases que se basan en la comprensión de los conceptos orientado a objetos (OO).

El enfoque orientado a objetos permite que los objetos estén auto-contenidos. Los

objetos existen por sí mismos, con una funcionalidad para invocar comportamientos de

otros objetos. Por definición son modulares, es decir, pequeñas unidades lógicas de

códigos independientes entre sí que se comunican entre ellas mediante mensajes en su

construcción. Esto quiere decir que son entidades completas y, por lo tanto, tienden a

ser altamente reutilizables.

Las aplicaciones orientadas a objetos se constituyen sobre el paradigma de los

mensajes a otros objetos.

Por lo general la mayoría de los programadores desarrolla sobre un lenguaje y solo

utiliza su propio estilo de programación. Desarrollan sobre un paradigma forzado por el

lenguaje que utilizan, tienden a no enfrentarse a métodos alternativos de resolución de

un problema y como resultado se presentan con la dificultad de ver las ventajas de elegir

un estilo más apropiado al problema a manejar. Autores como Bobrow y Stefik (1986,

citados en Booch-Grady, 1996) sugieren que existen cuatro clases de estilo de

programación:

Orientada a procedimientos (Algoritmos).



Orientada a objetos (Clases y objetos).

Orientada a la lógica (Expresado en cálculo de predicados).

Orientada a reglas (Reglas if-Then).

Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software

que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque

representa un dominio en términos de conceptos compuestos por verbos y sustantivos,

clasificados de acuerdo a su dependencia funcional.

En este método de análisis y diseño se crea un conjunto de modelos utilizando una

notación acordada, como por ejemplo, el lenguaje unificado de modelado (UML). ADOO

aplica técnicas de modelado de objetos para analizar los requerimientos en un contexto

(un sistema de negocio, un conjunto de módulos de software) y para diseñar una solución

para mejorar los procesos involucrados. Este método no está restringido al diseño de

programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las

metodologías de análisis y diseño más modernas son casos de uso guiados a través de

requerimientos, diseño, implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado

en análisis y diseño orientado a objetos.

Las estrategias que se utilizan para hacer un correcto desarrollo orientado a objetos son:

análisis, diseño y programación. En el análisis se consideran las actividades que hay que

hacer para desarrollar un programa OO y se identifican los objetos, transformándolos en

entidades y operaciones para asociarlos con el problema a resolver. En el diseño, los

objetos se relacionan con la solución del problema. Finalmente, en la programación se

hace la codificación del problema en algún lenguaje con orientación a objetos.

1.1.2. Características

El modelo AOO se basa en el concepto de objeto. Un objeto que tiene estado,

comportamiento e identidad. La estructura y el comportamiento de los objetos son

similares y están definidos en su clase común.

De tal modo, los sistemas deben estar funcionando siempre de manera correcta, su

complejidad a veces es tan grande que el mismo ser humano o su capacidad intelectual

se ve excedida, por lo que resulta imposible comprenderlo en su totalidad por una sola

persona.

Así, el software es complejo de forma innata, es una característica esencial de él. Es

complejo porque hereda la complejidad del problema, la dificultad de gestionar el proceso

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://es.wikipedia.org/wiki/UML

http://es.wikipedia.org/wiki/Dise%C3%B1o_orientado_a_objetos



de desarrollo, la flexibilidad que se puede alcanzar a través del software y los problemas

que plantea:

1. El problema presenta tantos requisitos que compiten entre sí o se contradicen, y

esas contradicciones existen porque los usuarios no saben expresar sus necesidades

de forma clara para que las otras personas que participan en el proyecto lo puedan

entender.

2. Los requisitos, además, son cambiados con frecuencia durante el desarrollo,

incluso porque la mera existencia de un proyecto de solución altera al sistema real.

3. Un sistema grande, debido a la inversión financiera que implica, no puede

desecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian, debe

evolucionar, considerando:

Evolución del software: responder al cambio de requerimientos.

Mantenimiento del software: corregir errores.

Conservación del software: emplear recursos para mantener en operación un elemento

de software anticuado y decadente.

4. La principal tarea del grupo de desarrollo es dar una ilusión de simplicidad para los

usuarios de esta complejidad arbitraria del problema, se hace lo posible por escribir

menos código pero a veces es imposible y más en un sistema tan grande, por lo que

se debe recurrir a la aplicación de varias técnicas de re-utilización de código

existente.

5. Debe también enfrentarse la existencia de miles de módulos separados y esto

implica un grupo de desarrolladores, nunca una única persona.

6. Un proyecto de software es muy frecuentemente apoyado en pilares construidos

por los mismos desarrolladores, por lo que el desarrollo del proyecto de software

sigue siendo una tarea muy laboriosa.

7. En algunos sistemas, una pequeña modificación en la entrada provoca una

pequeña modificación en la salida. Mientras que en otros, y sobre todo de gran

tamaño, se percibe una explosión combinatoria que hace que la salida se modifique

enormemente.

8. Se intenta diseñar los sistemas con una separación de intereses, de forma que el

comportamiento de una parte del sistema tenga el mínimo impacto en el

comportamiento de otra parte del sistema.

9. En un sistema de gran volumen, uno debe contentarse con un grado de confianza

determinado a lo que refiere su corrección, ya que no puede llevarse a cabo una

prueba a fondo exhaustiva por no tener las herramientas matemáticas ni intelectuales

para un sistema no continuo.

10. Las consecuencias de la complejidad ilimitada. Mientras más complejo es el

sistema, más abierto está al derrumbamiento total.

11. Crisis del software: ha existido tanto tiempo que debe considerarse normal. Es

cuando se pretende dominar la complejidad del sistema a un extremo que lleva al



presupuesto a niveles excedentes y que transforman en deficiente al sistema

respecto a los requerimientos fijados.

1.1.3. Ventajas

Los beneficios del enfoque OO, de acuerdo con Booch-Grady (1996), son:

Primero, el uso del modelo OO nos ayuda a explotar el poder expresivo de todos

los lenguajes de programación basados en objetos y los orientados a objetos,

como Smalltalk, Object Pascal, C++, CLOS, Ada y recientemente Java.

Segundo, el uso del modelo OO alienta el re-uso no solo del software, sino de

diseños completos.

Tercero, produce sistemas que están construidos en formas intermedias estables

y por ello son más resistentes al cambio en especificaciones y tecnología.

Se considera que el principal beneficio del AOO, es que da un esquema para formalizar

el modelo real.

El análisis orientado a objetos (AOO) es un método de análisis que examina los

requerimientos desde la perspectiva de las clases y objetos encontrados en el

vocabulario del dominio del problema. El diseño orientado a objetos es un método de

diseño que abarca el proceso de descomposición orientado a objetos y una notación

para representar ambos modelos (lógico y físico), como los modelos estáticos y

dinámicos del sistema bajo diseño.

Dentro de las metodologías del análisis y diseño orientado a objetos, hay una variedad

de métodos en la actualidad. Muchos de los métodos pueden ser clasificados como

orientados a objetos porque soportan de manera central los conceptos de la orientación

a objetos. Algunas de las metodologías más conocidas y estudiadas hasta antes de UML

(Jacobson 1996, citado en Booch-Grady, 1996) son:

METODOLOGÍA AUTOR

Diseño orientado a

objetos (DOO) Grady Booch

Técnica de modelado de

objetos (TMO) Rumbaugh

Análisis orientado a

objetos (AOO) Coad/Yourdon

Jerarquía de diseño

orientada a objetos

(JDOO)

ESA

Diseño estructurado Wasserman



orientado a objetos

(DEOO)

Análisis de sistemas

orientado a objetos

(ASOO)

Shaler y Mellor, entre

otros

Actualmente las metodologías más importantes de análisis y diseño de sistemas

orientados a objetos se han basado en lo que es el UML, bajo el respaldo del Grupo

Administrador de objetos.

El modelo de objetos ha demostrado ser aplicable a una amplia variedad de dominios de

problema. Hoy en día, el ADOO puede que sea el único método que logre emplearse para

atacar la complejidad innata de muchos sistemas grandes. Sin embargo, puede no ser

aconsejable en dominios, no por razones técnicas sino por cuestiones como falta de

personal con entrenamiento adecuado o buenos entornos de desarrollo.

Lo interesante de la Programación Orientada a Objetos (POO) es que proporciona

conceptos y herramientas con las cuales se modela y representa el mundo real tan

fielmente como sea posible.

Actividad 2. Características y ventajas de la programación OO

Con el fin de reflexionar sobre la importancia de hacer un adecuado análisis y diseño

previo para realizar un buen programa, tomando en cuenta los temas abordados, realiza

lo que se te pide a continuación:

1. Retoma los conceptos desarrollados hasta ahora. 2. Identifica las diferencias entre análisis, diseño y programación orientada a objetos. 3. Ingresa al foro y realiza lo que en él se te pide.

1.2. Identificación y conceptos básicos de modelos orientados a

objetos

El análisis orientado a objetos es una forma de hacer frente a la comprensión y solución

de problemas, usando modelos a partir de conceptos. La pieza fundamental es el objeto,

el cual se combina en una sola entidad.



Para dar énfasis sobre los conceptos en el análisis orientado a objetos, a continuación se

detallan los más básicos o utilizados con mayor frecuencia.

Objeto: Es una entidad bien definida, real o abstracta, que tiene sentido sobre el contexto

de alguna aplicación y un papel bien definido. A su vez se puede diferenciar en dos tipos:

Concretos: Ejemplo de objetos concreto, una unidad de almacenamiento, un

archivo de computadora, un automóvil, un profesor.

Conceptuales: Ejemplo de objetos conceptuales, un programa de computadora,

una variable de programación, un pensamiento.

Atributo: Es un valor atribuido a un objeto, por ejemplo un alumno es un objeto y sus

atributos podrían ser su número de control, su nombre y su calificación. Se entiende que

se pueden llegar a tener más atributos, pero si el contexto de la aplicación es solo obtener

un resultado específico, los atributos serán los únicos que son relevantes para esa

aplicación.

Comportamiento: Es el conjunto de cada acción o transformación que el objeto ejecuta,

también podría ser llamado operación y método. Por ejemplo, para el objeto alumno se

requiere de algunas acciones y transformaciones: asignar calificación, leer nombre y leer

número de control; estas acciones representan el comportamiento del objeto alumno. En

el caso de asignar calificación, leer nombre y leer número de control, se refieren a

transformaciones, ya que modificarán el valor de la calificación final.

Identificación: Cada objeto posee una identificación mediante la cual se puede hacer

alusión a él de modo exclusivo.

Clase: describe propiedades importantes para una aplicación y que ignora el resto. La

selección de clases es arbitraria y depende de la aplicación.

Instancia: Se considera que cada objeto es una instancia de su clase. Toda clase

describe un conjunto posiblemente finito de objetos individuales.

Identidad. Se refiere a que cada objeto conserva de manera inherente su propia

identidad. O sea, 2 objetos son distintos aún si el valor de todos sus atributos es idéntico.

Por ejemplo, los 8 peones negros de un juego de ajedrez, son todos negros, tienen las

mismas dimensiones, textura, pero todos son diferentes, existen y tienen su propia

identidad. Dos gotas de agua es otro ejemplo de la característica de identidad de los

objetos.

Clasificación. Se refiere a que los objetos con los mismos atributos y comportamiento –

métodos-, son agrupados en clases. Cada objeto perteneciente a una clase, se dice que

es una instancia de la clase. Así que una clase, representa a un posible conjunto infinito



de objetos individuales. Por ejemplo a todos los alumnos que aparecerán en la lista de

calificaciones finales, los clasificamos en la clase Alumno. A todos los amigos que

registramos en nuestra agenda, los podemos clasificar en la clase Persona. (Kendall,

2005 y Booch-Grady, 1996)

1.2.1. Abstracción

En la abstracción la mente humana modela la realidad en forma de objetos. Para ello

busca semejanzas entre la realidad y la posible implementación de objetos del programa

que simulen el funcionamiento de los objetos reales.

Los humanos entendemos la realidad como objetos ya definidos y no como un conjunto

de situaciones menores que se unen para dar forma a algo. No es necesario conocer

detalles del cómo, cuándo, donde o por qué las cosas, solamente necesitamos saber que

cuando queremos caminar lo haremos y punto.

Es la caracterización de un objeto de acuerdo a las propiedades que nos interesen en un

instante de tiempo. Las características escogidas son relativas a la perspectiva del

observador.

Figura 1.1. Abstracción.

1.2.2. Encapsulamiento

Cuando un objeto es encapsulado tenemos la libertad de saber qué información se hace

pública o no, para ello podemos hacer privados e inaccesibles los datos de este objeto a

través otro previamente publicado.

Con esto logramos que los datos solo sean utilizados por su interfaz dejando de lado

cómo está implementada, haciendo así, más fácil la utilización del mismo.



Así pues, la manera de ocultar los detalles de la representación interna de un objeto es

presentando solo la interface para el usuario.

Figura 1.2. Encapsulamiento.

1.2.3. Modularidad

A través de la modularidad, se propone al programador dividir su aplicación en varios

módulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de ellos

con un sentido propio.

Esta fragmentación disminuye el grado de dificultad del problema al que da respuesta el

programa, pues se afronta éste como un conjunto de problemas de menor dificultad,

además de facilitar la comprensión del programa.

1.2.4. Herencia

La herencia se base en la capacidad para reflejar la abstracción que realiza

automáticamente y se refiere a compartir atributos y métodos entre objetos que se

relacionan de manera jerárquica durante un proceso de análisis de información.

Se percibe en la realidad como un agregado de objetos relacionados. Estas

interrelaciones, pueden verse como un conjunto de generalizaciones que se asimilan con

el tiempo. Así pues, la herencia es el mecanismo fundamental de relación entre clases en

la orientación a objetos.

Del mismo modo, las distintas clases de un programa se organizan mediante la jerarquía.

La representación de dicha organización da lugar a los denominados árboles de herencia:



Figura 1.3. Ejemplo de árbol de herencia

La capacidad de descomponer un problema o concepto en un conjunto de objetos

relacionados entre sí, y cuyo comportamiento es fácilmente identificable, puede ser muy

útil para el desarrollo de programas informáticos. Del mismo modo,

Relaciona las clases de manera jerárquica; una clase padre o superclase sobre otras

clases hijas o subclases.

1.2.5. Polimorfismo

“Mediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto que

realice una acción determinada o que modifique su estado. El paso de mensajes se suele

implementar como llamadas a los métodos de otros objetos.

Desde el punto de vista de la programación estructurada, esto correspondería con la

llamada a funciones” (García, s/f: 1)

Ahora bien, el polimorfismo es una característica de la orientación a objetos, que significa

que un mismo método puede tener diferente manera de realizarse, en las diferentes

clases que haya bajo estudio. Cada objeto perteneciente a una clase y “sabe cómo”

ejecutar sus propios métodos. Cuando se programa orientado a objetos, el lenguaje de

programación automáticamente selecciona el método correcto para efectuar una cierta

acción o transformación sobre el objeto al que se aplica. Por ejemplo, si tenemos los

objetos bicicleta, carro, barco y les aplicamos la operación Mover, la acción se ejecuta de

manera diferente para cada objeto. Otro ejemplo típico es el de los objetos de la clase

Figura, digamos círculo, rectángulo, triángulo, apliquémosles la acción de Dibujar, cada

uno de ellos tendrá su propio método Dibujar definido, ya que la acción debe

implementarse de manera diferente para cada objeto.



Actividad 3. Ejemplos de sistemas

Esta actividad tiene como finalidad distinguir, en un primer acercamiento, cada uno de

los modelos del ciclo de vida del software. Realiza lo siguiente:

1. En un archivo de texto, realiza ejemplos de sistemas que un cliente pudiera necesitar

(por ejemplo, un sistema que controle una zapatería) y describe qué haría en cada una

de las etapas en los ciclos cascada y espiral incremental.

Ejemplo:

Modelo de ciclo de

vida de zapatería Etapa Descripción

Espiral Planificación En esta etapa en

la zapatería se va

a…

2. Guarda tu actividad con la nomenclatura DOO_U1_A3_XXYZ.

3. Envía el archivo a tu Facilitador(a) para recibir retroalimentación.

1.3. Ciclo de vida del software y tipos de ciclos

La metodología para el desarrollo de software tiene pasos establecidos en la realización y

administración de un proyecto para llevarlo a cabo con éxito. Para facilitar esto, se debe

dividir un gran proyecto en módulos más pequeños llamados etapas. Las acciones que

corresponden en cada una de ellas ayudan a definir entradas y salidas para cada una de

las etapas y sobre todo, normaliza el modo en que administraremos el proyecto.

1.3.1. Definición

Llevar a cabo la metodología para el desarrollo del software requiere seguir puntualmente

una serie de pasos o procesos para analizar, diseñar y realizar un producto software,

desde que surge la necesidad hasta que cumplimos el objetivo por el cual fue creado.

Desde un punto de vista puede considerarse que el ciclo de vida de un software tiene

capas claramente diferenciadas:



Planificación: planteamiento detallado que los pasos a seguir durante el

desarrollo del proyecto, considerando aspectos de tiempo y dinero.

Implementación: decidir las actividades que componen la realización del

producto.

Producción: EL proyecto es presentado al cliente o usuario final, sabiendo que

funciona correctamente y responde a los requerimientos solicitados en su

momento.

Figura 1.4. Ciclo de vida del software.

1.3.2. Espiral

Este ciclo de vida puede considerarse una variación del modelo prototípico que fue

diseñado por Boehm en el año 1988 (citado en Kendall, E., 2005). El modelo se basa en

una serie de ciclos repetitivos para ir ganando madurez en el producto final. Conforme se

va desarrollando el sistema se hace un primer prototipo se presenta al cliente y sobre este

se hacen adecuaciones y nuevos prototipos así se tiene un avance en espiral hasta llegar

a la perfección de todas las funcionalidades o módulos.

En este modelo hay cuatro actividades principales para las etapas:

Planificación: Relevamiento de requerimientos iniciales o luego de una iteración.

Análisis del riesgo: De acuerdo con el relevamiento de requerimientos decidimos

si continuamos con el desarrollo.

Implementación: Desarrollamos un prototipo basado en los requerimientos.

Evaluación: El cliente evalúa el prototipo, si da su conformidad termina el

proyecto. En caso contrario incluimos los nuevos requerimientos solicitados por el

cliente en la siguiente iteración.



Figura 1.5. Espiral.

1.3.3. Cascada

El primer modelo de proceso de desarrollo de software que se publicó, se derivó de

procesos de ingeniería de sistemas más generales (Royce, 1970, citado en Sommerville,

I. 2005).

A continuación se ve cómo de un diseño previo se deriva otro, dando así su nombre a

Cascada. Cayendo de una a otra, las etapas de este modelo se transforman en

actividades fundamentales de desarrollo:

1. Análisis y definición de requerimientos. Los servicios, restricciones y metas del

sistema se definen a partir de las consultas con los usuarios.

2. Diseño del sistema y del software. El proceso de diseño del sistema divide los

requerimientos en sistemas hardware o software.

3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software se

lleva a cabo como un conjunto o unidades de programas.

4. Integración y prueba del sistema. Los programas o las unidades individuales de

programas se integran y prueban como un sistema completo para asegurar que se

cumplan los requerimientos del software.



5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), esta

es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento

práctico. El mantenimiento implica corregir errores.

Figura 1. 6. Cascada.

1.3.4. Incremental

Este modelo está basado en varios ciclos Cascada realimentados aplicados

repetidamente, es decir que va incrementando las funcionalidades del programa. Se

realiza construyendo por módulos que cumplen las diferentes funciones del sistema, lo

que permite ir aumentando gradualmente las capacidades del software. Desarrollar un

módulo o módulos por separado resulta excelente modelo cuando es desarrollado por

varios programadores.

Figura 1. 7. Incremental.

El modelo de ciclo de vida incremental nos genera algunos beneficios como:

Construir un sistema pequeño siempre es menos riesgoso que construir un

sistema grande.

Como desarrollamos independientemente las funcionalidades, es más fácil relevar

los requerimientos del usuario.



Si se detecta un error grave solo se desecha la última iteración.

No es necesario disponer de los requerimientos de todas las funcionalidades en el

comienzo del proyecto y además facilita la labor del desarrollo con la conocida

filosofía de divide y vencerás

Este modelo de ciclo de vida no está pensado para cierto tipo de aplicaciones, sino que

está orientado a cierto tipo de usuario o cliente.

Actividad 4. Conceptos básicos de los modelos Orientados a objetos

Con el fin de distinguir cada uno de los conceptos básicos de la programación orientada a

objetos, en esta actividad debes proponer ejemplos que hagan referencia a cada uno de

ellos: abstracción, encapsulamiento, polimorfismo, modularidad, herencia, jerarquía y

paso de mensajes. Con base en lo anterior, realiza lo que a continuación se te pide:

1. En un archivo de texto, anota el nombre de cada concepto básico de los sistemas

orientados a objetos.

2. De acuerdo con la definición que se revisó en los temas anteriores, inventa un ejemplo

de la vida diaria que se apegue a cada uno de ellos.

3. Guarda tu actividad con la nomenclatura DOO_U1_A4_XXYZ.


Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en esta

primera unidad del curso, es necesario que resuelvas la autoevaluación de la unidad.

Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y

elegir la opción adecuada para cada uno.

Evidencia de aprendizaje. Mapa mental de los modelos orientados a

objetos

Como parte de la evaluación de esta unidad, llevarás a cabo esta actividad cuyo propósito

es organizar los conceptos abordados a lo largo de la unidad con la finalidad de tener

presente las definiciones revisadas. Realiza lo siguiente:



1. En un archivo de texto o Microsoft Visio, crea un mapa mental con las definiciones de

los temas tratados durante la presente unidad. Recuerda que un mapa mental contiene

cuadros de texto, líneas que representan uniones entre ellos e imágenes que pueden

substituir textos.

2. Consulta la Escala de evaluación.

3. Guarda tu evidencia con la nomenclatura DOO_U1_EA_XXYY.

4. Envía el archivo a tu Facilitador(a) para recibir retroalimentación. Recuerda que

puedes volver a enviar tu archivo tomando en cuenta las observaciones de tu

Facilitador(a).

Además de enviar tu trabajo de la Evidencia de aprendizaje, es importante que ingreses

al foro Preguntas de Autorreflexión y consultes las preguntas que tu Facilitador(a)

presente, a partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado

DOO_U1_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta

Autorreflexiones.

Cierre de la unidad

Has concluido la primera unidad del curso. A lo largo de ésta se revisaron conceptos

generales sobre el análisis orientado a objetos, su definición, características y ventajas.

Posteriormente identificaste los conceptos básicos de los modelos orientados a objetos,

tales como abstracción, encapsulamiento, modularidad, herencia y polimorfismo, cuyo

propósito fue dar un panorama para identificar un modelo orientado a objetos. De la

misma manera, se identificaron los ciclos de vida del software y los tipos de ciclos que

existen al diseñar un sistema orientado a objetos.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que se

acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, ya

estás preparado(a) para seguir con la unidad 2, en donde abordarás los requerimientos

para el análisis del diseño orientado a objetos, realizarás levantamientos de

requerimientos y la documentación necesaria, teniendo en cuenta los estándares que

deben cumplir y los tipos de modelos para el desarrollo de software.

Para saber más

Si deseas saber más acerca de la programación orientada a objetos, visita las siguientes

direcciones electrónicas:



I.1. INTRODUCCIÓN A LA PROGRAMACIÓN ORIENTADA A OBJETOS:

http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/

Programación orientada a objetos: http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm

Fuentes de consulta

Bibliografía básica

Booch-Grady (1996). Análisis y Diseño Orientado a Objetos con Aplicaciones.


Kendall, E. (2005). Análisis y Diseño de Sistemas. México: Pearson Educación.

Seen, J. (1990). Análisis y Diseño de Sistemas de Información. México: Mc Graw

Hill.

Bibliografía complementaria

Ciberaula (2010). Programación orientada a objetos. Recuperado el 10 de octubre

de 2011 de: http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/

Coad, P. y Yourdon, E. (1990). Object Oriented Programming. USA: Yourdon

Press.

Fowler, M. y Kendall, S. (2000). UML Gota a gota. México: Prentice-Hall.

Fernández, S. (1995). Fundamentos del diseño y la programación orientada a

objetos. México: McGraw Hill.

García, F. (s/f). I.1. Introducción a la programación orientada a objetos.

Recuperado el 10 de octubre de 2011 de:

http://zarza.usal.es/~fgarcia/doc/tuto2/I_1.htm

Microsoft Autorized Academic (2010). Principles of Components Desing 1518.

USA: Microsoft.

Sommerville, I. (2005). Ingeniería del Software. México: Pearson Educación.







Unidad 2. Requerimientos para el análisis del diseño Orientado a

Objetos

Propósito

La especificación de requisitos es la primera fase de todo ciclo de vida o metodología de

desarrollo de un proyecto informático. Dos son sus objetivos principales:

Identificar las necesidades del cliente, es decir, conocer y definir el problema.

Realizar un estudio de viabilidad económico, técnico y legal, a partir del cual se

pueda decidir sobre la continuación del proyecto, teniendo en cuenta las

alternativas de construcción del mismo que se nos planteen.

Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas

técnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no

solo en el terreno informático) que un primer paso necesario para solucionar un problema

es tenerlo definido correcta y detalladamente. Esto implica dos cosas:

Es fundamental centrar la necesidad del cliente para poder definir el problema que se va a

resolver, tratando de dejar claro lo que queda dentro y fuera del alcance del mismo. En

este momento se está hablando de la definición, desde el punto de vista puramente

técnico, del proyecto. Un aspecto importante a tener en cuenta es la identificación de los

tipos de usuarios potenciales que tendrá el sistema.


Distinguir los requerimientos del sistema orientado a objetos en su etapa de análisis para

definir su diseño mediante técnicas y estándares de especificación.


El trabajo de ir detallando la definición de un problema en forma de requisitos se realiza

de manera repetitiva, progresiva, incremental. Por un lado, supone la planificación,



realización y evaluación de las entrevistas con los clientes y usuarios finales del sistema,

que son los portadores de la información necesaria para conocer el problema y definir el

proyecto. Por otro lado, supone la identificación y descomposición reiterada (hasta el nivel

de detalle que en cada caso sea necesario) de los problemas y necesidades expresados

por el cliente y los usuarios, para así ir redactando un conjunto de requisitos formales.

Principalmente, se utiliza la siguiente técnica:

Entrevista. Es una conversación dirigida por objetivos entre un entrevistador, miembro del

equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final.

Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo

siempre a las opiniones del entrevistado. Él es nuestra fuente de información principal y

de la relación que establezcamos depende la facilidad o dificultad para conocer sus

necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos;

la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su

futuro trabajo, expertos reticentes a compartir conocimientos.

Durante la realización de una entrevista lo habitual es la toma de notas, para redactar más

tarde el informe de evaluación de la misma. Para la grabación en audio o en video es

preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si

esto va a interferir en la entrevista, haciéndole sentir incómodo. Pese a su costo, se va

generalizando el uso de videoconferencias para la realización de entrevistas remotas, con

la consiguiente comodidad para ambas partes.

Toda entrevista requiere de una preparación previa: establecer los objetivos, seleccionar

al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir

documentación, elegir el tipo de preguntas para finalmente utilizar la información recabada

para lograr los fines.

Según el tipo de preguntas, existen diferentes clases de entrevista:

Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la

entrevista, hacia preguntas abiertas.

Deductiva: al principio se hacen preguntas abiertas y se va acotando con

preguntas cada vez más cerradas.

Mixta: se utilizan ambos tipos de preguntas indistintamente

Algunos ejemplos de Preguntas Abiertas son los siguientes:

¿Qué le parece nuestra propuesta frente a otras que ha recibido?

¿Qué servicios le gustaría recibir de su sistema?



Para poder formular preguntas “cerradas” es necesario anticipar las posibles alternativas

de respuesta. Algunos ejemplos de preguntas cerradas:

¿Firmamos el contrato?

¿Le gusta nuestro producto?

2.1. Levantamiento de requerimientos

A partir de las entrevistas, reuniones, etc., se ha definido el problema; es decir, se ha

obtenido la Especificación de Requisitos. En ella se describe lo que el sistema nuevo

debe realizar. Y se ha averiguado, mediante un estudio de viabilidad, si el sistema se

puede desarrollar o no.

Ahora, se va a realizar el siguiente paso del Ciclo de Vida: Análisis del sistema. Consiste

en analizar los requisitos para centrarse en qué debe hacer el sistema.

Con el Análisis del sistema se pretende:

Organizar la información; es decir, reflejar la información del problema en un

formato gráfico, más fácil de manejar. Este formato hace que los requisitos sean

entendibles para el diseñador y, a la vez, facilita la comunicación con el usuario.

Depurar todo aquello que no interesa y concentrarse en lo que debe hacer el

sistema.

Sacar a la superficie y resolver posibles conflictos.

Dividir el problema en sub-problemas más fáciles de resolver.

Así pues, toda aplicación se apoya en tres pilares o consta de tres partes principales:

Procesos. Son la parte funcional de la aplicación. Reflejan las funciones o tareas

que debe realizar la aplicación, muestran cómo se transforman los datos.

Datos. Son la parte estática de la aplicación. Se refieren a la información que se

necesita almacenar.

Eventos. Son la parte dinámica de la aplicación. Muestran los aspectos del sistema

que cambian con el tiempo. Provocan la ejecución de la operación adecuada en

cada momento. Son los que activan la aplicación (la ponen en marcha) y propagan

esa activación a lo largo de la aplicación, desencadenando la ejecución de otras

operaciones. Los eventos llevan el control de la aplicación introduciendo el

dinamismo necesario para su ejecución. Los eventos tienen mucha relación con la

interfaz de la aplicación. Porque a través de la interfaz se introducen los eventos.



Los procesos dicen qué hay que hacer.

Los datos indican con qué hay que hacerlo.

Y los eventos muestran cuándo hay que hacerlo.

Los tres pilares son complementarios, no tiene más importancia uno que otro, se

necesitan los tres. En algunos sistemas predomina más uno que otro, pero siempre están

presentes los tres.

Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una

representación abstracta de la realidad. Por tanto, como resultado del análisis se

obtendrán:

Modelo de Procesos, de modelo de Datos y de modelo de Eventos

Modelo de Procesos: recoge qué funciones, actividades, tareas, acciones, debe

realizar la aplicación y cómo manejar los datos.

Modelo de Datos: describe la información que maneja la aplicación, los datos que

debe almacenar. Y muestra cómo organizarla.

Modelo de Eventos: Indica en qué momento debe ejecutarse cada acción. Para

construir cada modelo hay diferentes técnicas, algunas son complementarias.

Figura 2.1

En la fase de análisis se pretende que los modelos (de procesos, de datos y de eventos)

estén lo suficientemente detallados sin llegar a descender al diseño.

El análisis tiene por objetivo entender el problema: las necesidades del cliente, las

restricciones que se deben cumplir.

El diseño pretende obtener una solución óptima que cumpla todos los requisitos. Se

orienta hacia la máquina, centrándose en cómo crear un sistema software que reúna

todas las necesidades y cumpla todas las restricciones.

El levantamiento de requerimientos incluye tres tipos de actividad:



Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios para

determinarse cuáles son sus requisitos. Esto a veces también se llama acopio de

los requisitos.

Analizar requisitos: determinándose si los requisitos indicados son confusos,

incompletos, ambiguos, o contradictorios, y después resolviendo estas ediciones.

Requisitos de la grabación: Los requisitos se pueden documentar en varias

formas, tales como documentos de lenguaje natural, utilice los casos, historias del

usuario, o especificaciones de proceso.

Actividad 1. Análisis y diseño en un programa orientado a objetos

Con el fin de reflexionar sobre la asignatura, en el foro: Análisis y diseño en un

programa orientado a objetos construirás un concepto propio, tomando en cuenta los

temas abordados con anterioridad y los comentarios de tus compañeros. Para ello:

1. Retoma las lecturas del tema 2.1.Levantamiento de requerimientos.

2. Identifica todos los requisitos que se deben cumplir antes de un análisis y diseño

Orientado a objetos.

3. Ingresa al foro, genera una nueva entrada y participa.

2.2. Documentación para levantamientos y especificaciones

La documentación reúne todas las actividades dedicadas básicamente a planificar el

proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los

usuarios. El esquema formal que debe tener una especificación de requisitos es el

siguiente:

1. Índice

2. Descripción del ámbito y alcance del proyecto

3. Lista de usuarios participantes

4. Descripción del sistema actual

5. Catálogo (priorizado) de requisitos del sistema

a. Funcionales

b. No funcionales

i. Restricciones

ii. De funcionamiento



* Del sistema

* Requisitos software

* Requisitos hardware

iii. Manejo de excepciones

6. Análisis de alternativas

a. Descripción de la alternativa 1

b. Descripción de la alternativa 2

c. Descripción detallada de la alternativa seleccionada

i. Modelo lógico de procesos

ii. Análisis costo-beneficio

iii. Diferencias significativas con las demás alternativas

7. Apéndices (si es necesario)

2.2.1. Documentación

La documentación de los requerimientos, es una de la parte importante durante en el

análisis. En la práctica es común describir los requerimientos en un documento, llamado

especificación de requerimientos del software, su principal objetivo es de comunicar de

forma efectiva los requerimientos, objetivos del dominio.

En primera instancia la documentación contiene la información que aporta el cliente que

encarga la aplicación, contiene todos los registros de las reuniones de trabajo del grupo

de análisis.

Documentos básicos de análisis orientado a objetos:

Documentos de análisis

Especificación de requisitos o requerimientos

Diagramas de casos de uso

Escenarios y sub-escenarios

Prototipos y su evaluación

Todos los documentos deben estar identificados y codificados.

Identificación

Es necesario identificar todos los elementos del proceso de desarrollo de software de una

forma única.

El título debe reflejar de la mejor forma posible sus fines y su funcionalidad.

• Descripción



• Autores

• Versión. Notación decimal.

• Revisión. Autores

• Fecha

• Código de cada documento o diagrama

Documentos de análisis

Contiene la documentación que aporta el cliente que encarga la aplicación. También

contiene las actas de las reuniones de trabajo del grupo de análisis, es necesario un

secretario que tome acta y es necesario aprobar el acta de cada reunión por todos los

miembros.

2.2.2. Especificaciones

Expresa las características esenciales de un objeto, las cuales distinguen al objeto uno de

otro. A parte de distinguir los objetos también provee límites conceptuales, permitiendo

que se disponga de las características de un objeto que se necesite.

El objetivo principal de las especificaciones, es en entregar una especificación de

requisitos que ayuden a determinar de forma completa y correcta el diseño orientado a

objetos.

2.3. Estándares de Especificación

Las especificaciones del software determina el proceso de comprensión y definición

sobre los servicios que se requieren del sistema y de identificación de las restricciones de

funcionamiento y desarrollo del mismo. La ingeniería de requerimientos es un proceso

crítico en el proceso del software, los errores en esta etapa originan problemas

posteriores en el diseño e implementación del sistema.

En la siguiente figura se muestra el proceso de ingeniería de requerimientos. Éste

conduce a la producción de un documento de requerimientos, que es la especificación del

sistema. Normalmente en este documento los requerimientos se presentan en dos niveles

de detalle. Los usuarios finales y los clientes necesitan una declaración de alto nivel de

los requerimientos, mientras que los desarrolladores del sistema necesitan una

especificación más detallada de éste.



Figura 2.2

2.3.1. Fases de la estandarización

Existen cuatro fases principales en el proceso de estándares de ingeniería de

requerimientos:

1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer

con las tecnologías actuales de software y hardware. El estudio analiza si el sistema

propuesto será rentable desde un punto de vista de negocios y si se puede desarrollar

dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente

económico de elaborar. EI resultado debe informar si se va a continuar con un análisis

más detallado.

2. Obtención y análisis de requerimientos. Es el proceso de obtener los requerimientos

del sistema por medio de la observación de los sistemas existentes, discusiones con los

usuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar el

desarrollo de uno o más modelos y prototipos del sistema que ayudan al analista a

comprender el sistema a especificar.

3. Especificación de requerimientos. Es la actividad de traducir la información

recopilada durante la actividad de análisis en un documento que define un conjunto de

requerimientos. En este documento se pueden incluir dos tipos de requerimientos: los

requerimientos del usuario, que son declaraciones abstractas de los requerimientos del

cliente y del usuario final del sistema, y los requerimientos del sistema, que son una

descripción más detallada de la funcionalidad a proporcionar.

4. Validación de requerimientos. Esta actividad comprueba la veracidad, consistencia y

completitud de los requerimientos. Durante este proceso, inevitablemente se descubren



errores en el documento de requerimientos. Se debe modificar entonces para corregir

estos problemas.

Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de

forma estrictamente secuencial. El análisis de requerimientos continúa durante la

definición y especificación, y a lo largo del proceso surgen nuevos requerimientos. Por lo

tanto, las actividades de análisis, definición y especificación se entrelazan. En los

métodos ágiles como la programación extrema, los requerimientos se desarrollan de

forma incremental conforme a las prioridades del usuario, y la obtención de

requerimientos viene de los usuarios que forman parte del equipo de desarrollo.

2.3.2. Análisis de restricciones

Las restricciones son relaciones entre entidades de un modelo de objetos, el término de

entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restricción

reduce los valores que una entidad puede tomar.

Restricciones entre objetos. Determina el estado en el cual los objetos se

diferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina no

puede ser después de las 9:00, suponiendo que el horario de entrada al trabajo es

a las 9:00.

Restricciones entre atributos de un objeto: Determina los atributos específicos de

un objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombre

completo y no apellido paterno, apellido materno y nombre.

Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objeto

donde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumno

no puede aumentar su número de control.

Las restricciones simples pueden situarse en el modelo de objetos, restricciones

complejas aparecerán en el modelo funcional. Las restricciones no tienen por qué

aparecer inicialmente en el modelo de objetos, estas irán añadiéndose conforme se vaya

concretando en la definición del modelo.



Actividad 2. Requerimientos, fases y restricciones para diseñar un

programa

Con el fin de aplicar cada uno de los conceptos básicos de los estándares de

especificaciones de un análisis, diseña un programa con orientación a objetos haciendo

un documento que sirva como base para conocer los requerimientos para diseñar un

programa para un salón de belleza.

1. Plantea una situación hipotética o ve a preguntar a un salón de belleza con el

encargado o encargada acerca de qué le gustaría controlar por computadora (Obtención y

análisis de requerimientos).

2. En un archivo de texto escribe los requerimientos del usuario y del sistema, de

acuerdo a lo recabado en la entrevista (Especificación de requerimientos).

3. Apunta si es viable o no (Validación de requerimientos).

4. Guarda la Actividad con el nombre DOO_U2_A2_XXYZ. Donde XX son es apellido(s) y

YY nombre(s).


2.4. Modelos del desarrollo del software

Las metodologías se centra en una serie de combinaciones de los modelos de proceso

genéricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodología debe

definir con precisión los roles y actividades involucradas, junto con prácticas, guías de

adaptación.

Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guías

asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo,

por ejemplo, suele hablarse de métodos de análisis y/o diseño.

La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la

diversidad de propuestas y diferencias en el grado de detalle, información disponible y

alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones

utilizadas para especificar artefactos producidos en actividades de análisis y diseño,



podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas y

Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de

desarrollo, aquellas metodologías con mayor énfasis en la planificación y control del

proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de

Metodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, o

Peso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están más

orientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen a

equipos de desarrollo pequeños, hacen especial hincapié en aspectos humanos

asociados al trabajo en equipo e involucran activamente al cliente en el proceso.

Los métodos estructurados comenzaron a desarrollarse a fines de los 70‟s con la

Programación Estructurada, luego a mediados de los 70‟s aparecieron técnicas primero

para el Diseño (por ejemplo: el diagrama de Estructura) y posteriormente para el Análisis

(por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son particularmente

apropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4ta

generación.

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia),

MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodos

estructurados en el ámbito académico: Gane &Sarson, Ward &Mellor, Yourdon&DeMarco

e InformationEngineering.

Metodologías orientadas a objetos, va unida a la evolución de los lenguajes de

programación orientada a objeto, los más representativos: a fines de los 60‟s SIMULA, a

fines de los 70‟s Smalltalk-80, la primera versión de C++ por BjarneStroustrup en 1981 y

actualmente Java o C# de Microsoft. A fines de los 80‟s comenzaron a consolidarse

algunos métodos Orientados a Objeto

En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de

conseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta a

un objetivo más modesto, para dar lugar al UnifiedModelingLanguage (UML), la notación

OO más popular en la actualidad (Booch-Grady, 1996)).

Algunos métodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE

(Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh).

Algunas metodologías orientadas a objetos que utilizan la notación UML son:

RationalUnifiedProcess (RUP), OPEN, MÉTRICA (que también soporta la notación

estructurada).



2.4.1. Ágiles

Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema y

métodos ágiles para desarrollar sistemas orientados a objetos se encuentre la

metodología ágil. Es cuando el desarrollo de software es incremental (entregas pequeñas

de software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntos

constantemente con una cercana comunicación), sencillo (el método en sí mismo es fácil

de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de

último momento)

El modelado ágil también abarca un conjunto de principios esenciales. Además delos

principios esenciales de la programación extrema, el modelado ágil agrega principios tales

como "modelar con un propósito", "el software es su meta principal" y "viajar con poco

equipaje", una forma de decir que poca documentación es suficiente.

Entre las metodologías ágiles identificadas:

• Extreme Programming

• Scrum

• Familia de Metodologías Crystal

• Feature Driven Development

• ProcesoUnificado Rational, unaconfiguraciónágil

• Dynamic Systems Development Method

• Adaptive Software Development

• Open Source Software Development

2.4.2. Predictivos

Las metodologías no ágiles son aquellas que están guiadas por una fuerte planificación

durante todo el proceso de desarrollo; llamadas también metodologías tradicionales o

clásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construcción

del sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse como

metodologías tradicionales por el especial énfasis que presenta en cuanto a su

adaptación a las condiciones del proyecto (mediante su configuración previa a aplicarse),

realizando una configuración adecuada, podría considerarse Ágil.

La inspiración usual para las metodologías han sido disciplinas como las ingenierías civil o

mecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Los

ingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que



construir y cómo deben juntarse estas cosas. Muchas decisiones de diseño, como la

manera de controlar la carga sobre un puente, se toman conforme los dibujos se

producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una

compañía diferente, para ser construidos. Se supone que el proceso de la construcción

seguirá los dibujos. En la práctica los constructores se encuentran con algunos

problemas, pero éstos son normalmente poco importantes.

Como los dibujos especifican las piezas y cómo deben unirse, actúan como los

fundamentos de un plan de construcción detallado. Dicho plan define las tareas que

necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un

plan de trabajo y un presupuesto de construcción razonablemente predecibles. También

dice en detalle cómo deben hacer su trabajo las personas que participan en la

construcción. Esto permite que la construcción requiera menos pericia intelectual, aunque

se necesita a menudo mucha habilidad manual.

Así que lo que vemos aquí son dos actividades fundamentalmente diferentes. El diseño,

que es difícil de predecir y requiere personal caro y creativo, y la construcción que es más

fácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Una

vez que tenemos el plan de construcción, podemos ocuparnos de la construcción de una

manera más predecible. En ingeniería civil la construcción es mucho más costosa y

tardada que el diseño y la planeación.

Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecible

que pueda usar gente del más bajo nivel. Para hacerlo debemos separar el plan de la

construcción. Por consiguiente necesitamos entender cómo hacer el diseño de software

de modo que la construcción pueda ser sencilla una vez que el plan esté hecho.

¿Qué forma toma este plan? Para muchos, éste es el papel de notaciones de diseño

como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones

significativas usando UML, podemos armar un plan de construcción y entonces podemos

dar planes a los programadores como una actividad de construcción.

Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz de

convertir el código en una actividad de construcción predecible? Y en tal caso, ¿es la

construcción suficientemente grande en costo y tiempo para hacer valer la pena este

enfoque?

Todo esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil es

conseguir un diseño UML en un estado que pueda entregarse a los programadores. El

problema con un diseño tipo UML es que puede parecer muy bueno en el papel, pero

resultar seriamente fallido a la hora de la programación. Los modelos que los ingenieros

civiles usan están basados en muchos años de práctica guardados en códigos



ingenieriles. Además los problemas importantes, como el modo en que juegan las fuerzas,

son dóciles al análisis matemático. La única verificación que podemos hacer con los

diagramas UML es la revisión cuidadosa. Mientras esto es útil trae errores al diseño que

sólo se descubren durante la codificación y pruebas. Incluso los diseñadores

experimentados se sorprenden a menudo cuando convierten dichos diseños en software.

Otro problema es el costo comparativo. Cuando se construye un puente, el costo del

esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construcción.

En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se

sugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebas

unitarias, una inversión casi perfecta de las proporciones de la construcción del puente.

Aun cuando se consideren las pruebas parte de la construcción, el plan es todavía 50%

del total. Esto genera una pregunta importante sobre la naturaleza del diseño en software

comparado con su papel en otras ramas de la ingeniería.

Actividad 3. Cuadro Comparativo de modelos ágiles y predictivos

1. En un archivo de texto, realiza un cuadro comparativo de los modelos ágiles y

predictivos, teniendo en cuenta las definiciones vistas en los temas anteriores.

Ejemplo:

2. Guarda la actividad con el nombre DOO_U2_A3_XXYZ.Donde XX es tu apellido(s) y

YY nombre(s).




Autoevaluación


primera unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda

que es muy importante leer cuidadosamente los planteamientos indicados y elegir la

opción adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para diseñar un programa

Orientado a Objetos

Como parte de la evaluación de esta unidad, debes llevar a cabo una actividad cuyo

propósito es conceptuar el proceso.

1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los

estándares para diseñar un programa con OO para el control de una papelería y

menciona el modelo de software a aplicar en la misma.

2. Dale formato.

3. Guarda la evidencia con el nombre DOO_U1_EA_XXYZ.


Cierre de la unidad

Has concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentación de

requerimientos para el análisis orientado a objetos, comenzando con la parte de

levantamiento de requerimientos, que incluye el describir cuáles son los requerimientos y

que actividades necesitas realizar para el levantamiento de los mismos.

También identificas cual es la documentación para el levantamiento y que

especificaciones debe cumplir considerando sus estándares, divididos en sus fases y

análisis de restricciones. Por último en esta unidad debes distinguir que modelos del

desarrollo de software se manejan y si son ágiles o predictivos.




acaban de mencionar no te sean familiares o no los recuerdes, de no ser este tú caso, ya

estás preparado(a) para seguir con la unidad 3, en donde continuarás con la

Metodologías de Diseño para la Generación de Sistemas Orientados a Objetos, tales

como Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la última unidad del curso

de Análisis y Diseño Orientado a Objetos.

Fuentes de consulta

Booch-Grady (1996) Análisis y Diseño Orientado a Objetos con aplicaciones. México:

Pearson Educación.

Cueva, J. (2005) Ingeniería del Software. Madrid: Pearson Educación.

Cueva, J. (2005) Análisis orientado a objetos, en:El proceso de desarrollo de

software. Recuperado el 22 de julio de 2011 de:

http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf

Fowler, M. (2003) La nueva metodología. Traducción de Alejandro Sierra para

programacionextrema.org. Recuperado el 22 de julio de 2011 de:

http://www.programacionextrema.org/articulos/newMethodology.es.html

García, S. y Morales, E. (2003) Desarrollo de aplicaciones informáticas. Análisis y

diseño detallado de aplicaciones informáticas de gestión. México: Ed. Thompson.

Kendall, E. (2005) Análisis y Diseño de sistemas. México: Pearson Educación.

Letelier, P. y Penadés, M. (s/f) Metodologías ágiles para el desarrollo de software:

eXtremeProgramming (XP). Universidad Politécnica de Valencia. Recuperado el 22

de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf

WorldLingo (2011) Análisis de requisitos. WorldLingoTranslations LLC. Recuperado el

22 de julio de 2011 de:

http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis

http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf

http://www.programacionextrema.org/articulos/newMethodology.es.html

http://www.willydev.net/descargas/masyxp.pdf

http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis



Unidad 3. Metodologías de diseño para la generación de sistemas

orientados a objetos


En las metodologías de análisis y diseño orientado a objetos, se utilizan algunos

conceptos que se definen a continuación.

Método. Es un conjunto de lineamientos y reglas, incluyendo los siguientes

componentes.

Conceptos de modelado. Permiten la captura de la semántica y el conocimiento

acerca de un problema y su solución.

Modelo es una representación formal de un sistema con cierto nivel de

abstracción. En las etapas de especificación de requerimientos y análisis el nivel

de abstracción normalmente es alto, omitiendo detalles de implementación.

Meta modelo. Es un modelo que describe otros modelos, describe los conceptos

del método modelo y sus relaciones, define los modelos legales que pueden ser

construidos dentro del método, describe la información que debe ser capturada.

Vistas y notaciones. Son útiles en la presentación fundamental del modelo de

información para que los seres humanos puedan comprenderla, examinarla y

modificarla en su caso.

Una vista solo muestra una parte de la semántica del modelo y diferentes vistas

pueden presentar la misma información en varias formas.

Notación. Permite construir, examinar y manipular modelos, el mismo modelo se

puede dibujar de diferentes maneras mediante el uso de diferentes símbolos,

donde algunos de ellos pueden tener el mismo significado. Cada persona puede

adoptar su propio formato para describir sus diagramas.

Proceso de desarrollo iterativo. Representa una secuencia de pasos para la

construcción e implementación de modelos. El proceso puede estar distribuido en

varios niveles de detalle, desde el nivel más alto del proyecto, hasta etapas

específicas para la construcción de modelos de bajo nivel. El proceso indica qué

modelos se deberán construir y cómo construirlos.

Proceso. Es la guía que indica como producir un modelo, proporciona un esqueleto

de trabajo (frameworks) para el desarrollo, describe los artefactos a ser producidos

y las etapas para producirlos. A alto nivel, describe el desarrollo del ciclo de vida y

las etapas de iteración dentro de él. A bajo nivel describe un esqueleto de trabajo

para la producción de modelos; las etapas para la construcción del modelo,

lineamientos para describir componentes de él, principios de diseño a seguirse,



mediciones de calidad, referencias cruzadas, reglas de consistencia y banderas

rojas para identificar posibles problemas.

Patrón. Es una solución estándar escrita para resolver un problema, basada en

una secuencia de tiempo. No existen museos de programas donde los nuevos

diseñadores puedan aprender, emulando programas que allí existen, mas bien,

tratan de captar ideas de los diseñadores expertos. Actualmente existe un

Movimiento de Patrones con el propósito de coleccionar, catalogar y explicar

patrones útiles de diseño, de tal forma que otros diseñadores puedan aprender de

ellos. Por lo tanto, Los Patrones son resúmenes de casos de diseño basados en la

experiencia.

Reglas de Diseño. Son estados o propiedades que deberán llevarse a cabo u

omitirse en un diseño o estrategias generales de diseño a utilizar. Tips y Reglas de

dedo. Son recomendaciones que se aplican donde sea necesario, no se organizan

en etapas. Son presentaciones informales de patrones.

En los métodos AOO/DOO existen dos tipos principales, dividiendo a estos en:

Estáticos (enfocados a datos), lo importante es la estructura de datos anexa a los

objetos y las operaciones que sobre ella operan.

Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un

objeto tiene sentido en estos métodos cuando exhibe un comportamiento

diferencial respecto del resto delos objetos.



En la tabla anterior se mezclan métodos de análisis y de diseño porque, pese a lo que

anuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño se

difumina, aquí presentamos los más utilizados y que dieron origen al que actualmente se

utiliza para el ADOO.

Propósito

Con el transcurso de esta unidad ubicarás las diferentes metodologías para el diseño de

sistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /

Ingeniería de software orientado a objetos), OMT (Object Modeling Technique / Técnica

de modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado de

Modelado) las cuales nos servirán después de hacer un análisis para hacer un buen

diseño apoyado con estas técnicas.




Comparar las metodologías de diseño para la generación de sistemas orientados a

objetos mediante los diagramas con los métodos de modelado Booch, OOSE, OMTy

UML.

3.1. Booch

Es una metodología que se utiliza en el análisis y diseño de software creada por Booch

durante su estancia en Rational Software Corporation.

El método BOOCH define modelos para describir un sistema, soportando el desarrollo

iterativo e incremental. El método incluye diferentes diagramas según el enfoque que se

le dé ya sea:

De clases

De objetos

De transición de estados

De módulos

De procesos

De interacción


El método cuenta con una notación expresiva y bien definida que le permite al diseñador

expresar sus ideas y concentrarse en problemas más serios.

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.



Dimensión lógica: 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.

Dimensión física: Describe la composición concreta en cuanto a hardware y software del

contexto o implantación del sistema.

Dimensión estática: Están formados por los diagramas de:

1.- Diagramas de clases: Muestra la existencia de clases y sus relaciones, en la visión

lógica de un sistema, utilizada en la etapa de análisis.

2.- Diagramas de objetos: Muestran la existencia de objetos y sus relaciones en la etapa

de diseño lógico de un sistema.

3.- Diagramas de módulos: Muestran la asignación de clases y objetos a módulos en el

diseño físico de un sistema.

4.- Diagramas de procesos: Muestran la asignación de procesos a procesadores en el

diseño físico de un sistema.

Dimensión dinámica: La semántica dinámica de un problema se expresa mediante los

siguientes diagramas:

1.-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.

2.- 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.1.2. Modelos

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.



La figura siguiente 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:

Figura 3.1. Clase

Los atributos denotan una parte de un objeto agregado, durante el diseño expresan una

propiedad singular de la clase.

A Nombre del atributo solamente.

C Clase del atributo solamente.

A:C Nombre y clase del atributo.

Las 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).

Las relaciones de clase representan una colaboración con otras clases de diversas

maneras. Las conexiones esenciales entre clases incluyen las siguientes relaciones:

Figura 3.2. Conexiones entre clases



La asociación conecta dos clases y denota una conexión semántica, se etiquetan con

expresiones sustantivas, denotando la naturaleza de la relación.

La 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.

La 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 está en el otro extremo denota la parte cuyas instancias están

contenidas por el objeto agregado.

La 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.

Figura 3.3. Utilización

Diagramas de 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 en la figura siguiente 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.



Figura 3.4. Objeto

Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otros

objetos, un enlace es una instancia de una asociación, al igual que un objeto es una

instancia de una clase.

Figura 3.5. Relaciones entre objetos

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.

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

Figura 3.6. Objetos activos

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.

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

las entidades.

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

módulo engloba la declaración o definición de clases, objetos y otros detalles del lenguaje.

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 módulo 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 dirigidas para indicar conexiones entre procesadores y/o

dispositivos.



Figura 3.7. Diagrama de procesos

El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunque

está 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, entregado en tiempo, y es flexible al cambio y al crecimiento.

3.2. OOSE

Este método fue desarrollado por Ivar Jacobson OOSE “un enfoque para el manejo de

casos de uso”, este modelo de casos de uso sirve como un modelo central para otros

modelos.

Este modelo es la base en la etapa de análisis, construcción y prueba.

OOSE presenta cinco técnicas para modelar un sistema:

Modelo de requerimientos: delimita el sistema y define su funcionalidad.

Modelo de análisis: estructura el sistema, modelando tres tipos de objetos (objetos

de interface, objetos entidad y objetos de control).



Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente de

implementación. Consiste de diagramas de interacción y diagramas de transición

de estados.

Modelo de implementación: consiste en el código fuente de los objetos

especificados en el modelo de diseño.

Modelo de prueba: es llevado a cabo mediante la realización de pruebas al modelo

de implementación.

La idea básica de estos modelos es capturar el concepto inicial de todos los

requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos

es importante. Para ser posible el mantenimiento del sistema es también necesario que

los modelos sean tangibles.


Este método proporciona un soporte para el diseño creativo de productos de software,

inclusive a escala industrial. El autor plantea el problema del diseño y construcción de

software haciendo una comparación con la industria de la construcción, contemplando las

siguientes fases:

Herramientas. Soportan todos los aspectos de la empresa, explícitamente las

actividades de arquitectura, métodos y procesos.

Procesos. Permite el escalamiento de los métodos, de tal forma que puedan ser

aplicados a proyectos de forma interactiva y en partes.

Métodos. Establece de manera explícita los procedimientos etapa por etapa que

deben seguirse para aplicar la arquitectura al proyecto.

Arquitectura. Una buena estructura del sistema es fácil de entender, de cambiar y

realizar pruebas y mantenimiento. Las propiedades del sistema determinan cómo

la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la

arquitectura son extremadamente importantes y forman la base del método.

Diseño creativo. Las actividades creativas de un desarrollo, consisten en la

transformación de un conjunto de requerimientos y nociones vagas, en un plan

estructurado de construcción y un plan de acción para su implementación .El diseño

creativo tomando como referencia una base arquitectónica es seguir paso a paso los

métodos y procesos con la asistencia de herramientas, para convertir los requerimientos

dentro de una arquitectura viable para la construcción de un proyecto incluyendo la

creación de prototipos.



Un aspecto importante durante el desarrollo del sistema, es considerar explícitamente el

proceso de cambio.

Todos los sistemas cambian durante su ciclo de vida. Hoy en día el desarrollo de los

nuevos métodos es conocer qué cambios son los principales en la parte global del ciclo

de vida, así como el costo del sistema. Una industrial del proceso debe por lo tanto saber

sobre los cambios del sistema. Un sistema normalmente desarrolla cambios

incorporándose en nuevas versiones.

La primera versión de un sistema representa una pequeña parte de una composición

durante el ciclo de vida del sistema.

Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva

versión de un sistema, así como para un sistema totalmente nuevo. La diferencia radica

en que las entradas para cada etapa cambian en cada ciclo de vida.

Modelo de análisis. Especifica el comportamiento funcional del sistema bajo

prácticamente circunstancias ideales y sin hacer alusión a un ambiente particular de

implementación.

Construcción. La primera actividad en la construcción consiste en la implementación de

los detalles que conciernen a la arquitectura y construcción del plan, que es ir de una

mayor abstracción a concretizar más el plan.

Diseño. Formaliza el modelo de análisis en términos del ambiente de implementación y

especifica la identidad de los bloques de construcción.

Prueba del sistema. Consiste en la verificación del trabajo de cada uno de los paquetes

de servicio definidos en el modelo de análisis Esta fase tiene lugar en varios niveles,

desde funciones específicas, hasta el sistema completo.

Desarrollo incremental. El desarrollo del sistema es usualmente un proceso el cual toma

varios años para su terminación. La especificación es seguida por el análisis, la

construcción y prueba del sistema completo. Este método puede trabajar si todos los

requerimientos del sistema son conocidos del conjunto de salida.

En la mayoría de los casos, conviene mejor desarrollar el sistema etapa por etapa,

empezando con unas cuantas funciones principales, como se va aclarando la

comprensión del sistema en cuanto a su funcionalidad se van agregando nuevas

funciones, de esta forma el sistema va creciendo.

Sistema de desarrollo y metodología. Cuando se desarrolla un sistema grande es

importante conocer cómo cada uno de los pasos del método interactúa y cómo ellos



compiten dentro del desarrollo del proceso. Se hace hincapié en la discusión entre el

proceso de desarrollo y las ideas básicas que hay detrás del método lo que determina la

selección de una arquitectura de un universo de arquitecturas.

3.2.2. Modelos

El sistema de desarrollo es una tarea compleja. Algunos aspectos diferentes han sido

tomados en consideración. Se trabaja con 5 modelos:

1. El modelo de requerimientos: El objetivo es la captura de requerimientos

funcionales.

2. El modelo de análisis: El objetivo es dar al sistema una estructura de objetos

robusta y flexible a los cambios.

3. Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetos

en el ambiente actual de implementación.

4. El modelo de implementación: Tiene como objetivo implementar el sistema.

5. El modelo de prueba: Su objetivo es verificar el sistema.

La idea básica de estos modelos es capturar el concepto inicial de todos los

requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos

es importante. Para hacer posible el mantenimiento del sistema es también necesario que

los modelos sean tangibles.

Modelo de requerimientos

Actores y Casos de Uso

La primera transformación hecha de la especificación de requerimientos para el modelo

de requerimientos consiste en:

Un modelo de caso de uso

Descripción de la interface

Un modelo en el dominio del problema

Figura 3.8. Modelo de caso de uso



El modelo de caso de uso utiliza actores y caso de uso. Estos conceptos son usados para

definir si existe contacto externo con el sistema (actores), y qué debería ser hecho por el

sistema (caso de uso).

Los actores representan quienes interactúan con el sistema. Representan todas las

necesidades de cambio de información con el sistema. Dado que el actor representa la

parte exterior del sistema no se describirán detalles de ellos.

La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el

sistema, mientras que el actor es un rol que el usuario puede jugar.

Modelo de análisis

Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones

del sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha sido

desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema.

La información para este sistema se enfoca en la captura de:

Información: Especifica la información de ayuda en el sistema. Así como describe

el estado interno del sistema.

Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica

cuándo y cómo el sistema cambia de estado.

Presentación: Detalla la presentación del sistema al mundo exterior.

Figura 3.9. Dimensiones del modelo de análisis

Existen varios tipos de objetos usados para la estructura del sistema en el modelo de

análisis



Figura 3.10. Tipos de objeto

Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis, sin

embargo cada uno de ellos tiene cierta inclinación hacia una de las dimensiones.

Figura 3.11. Dimensiones del modelo de análisis

El modelo de diseño

El proceso de construcción edifica el sistema usando tanto el modelo de análisis y el

modelo de requerimientos. Primero se crea el modelo de diseño que es un refinamiento y

formalización del modelo de análisis. Al inicio del trabajo cuando se desarrolla el modelo

de diseño es para adaptarlo a la implementación del ambiente actual.

Figura 3.12. Implementación del ambiente

Una diferencia entre el modelo de análisis y el modelo de diseño es que el modelo de

análisis debe ser visto como un modelo conceptual o lógico del sistema, y el modelo de



diseño contiene el código, por lo cual el modelo de diseño deberá ser una representación

de la manera como el código fuente es estructurado, manejado y escrito.

Figura 3.13. Consecuencias del ambiente

El modelo de Implementación

La implementación del modelo consiste de la notación del código. La información de

espacio es la opción del lenguaje de programación que se usa. No necesariamente se

requiere de un lenguaje de programación orientada a objeto, sin embargo, si se

recomienda el uso de un lenguaje de programación orientada a objeto, desde la

concepción inicial hasta la construcción. La base para la implementación es el modelo de

diseño. Aquí se especifica la interface década bloque.

El modelo de prueba

El modelo de prueba es el último modelo a construir. Describe simplemente el estado de

resultados de la prueba. El modelo de requerimientos de nuevo representa una

herramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos se

comuniquen correctamente en dicho caso de uso. De manera simular se verifica la

interface de usuario, descrita en el modelo de requerimientos, con todo lo anterior, el

modelo de requerimientos es la base de verificado para el modelo de prueba.

3.3. OMT

Un modelo es una abstracción de algo, con la finalidad de comprenderlo, antes de

construirlo, ya que un modelo omite los detalles no esenciales, es más sencillo

manejarlos, que manejar la entidad original.

Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos

modelo dinámico y modelo funcional.




El modelo de objetos. Es el modelo más importante, ya que en él se identifican las clases

dentro del sistema junto con sus relaciones, así como sus atributos y operaciones, lo que

representa la estructura estática del sistema. El modelo de objetos se representa

mediante un diagrama de clases.

El modelo dinámico. Representa los aspectos temporales de comportamiento "de control

del sistema, mediante la secuencia de operaciones en el tiempo.

El modelo funcional. Representa los aspectos transformacionales "de función" del

sistema, mediante la transformación de valores de los datos. Se representa mediante un

diagrama de flujo.

Cada modelo describe un aspecto del sistema pero contiene referencias a los demás

modelos. Lo cual indica que los tres no son totalmente independientes.

Pasos del proceso de desarrollo orientado a objetos:

Conceptualización: Se describen los requerimientos para la solución del sistema.

Comienza identificando las necesidades desde el punto de vista de los usuarios. Dicha

información puede ser extraída de los casos de uso y del dominio del problema.

Análisis: Entender y modelar el problema en el dominio de la aplicación.

Diseño del sistema: Determinar la arquitectura del sistema en términos de subsistemas.

Diseño de objetos: Refinar y optimizar el modelo de análisis, agregando conceptos de

programación.

Código: Implementar las clases de objetos en un lenguaje de programación.

Pruebas: se realizan para verificar el comportamiento de las clases y objetos que se

encuentran descritos en los escenarios.

Figura 3.14. Proceso de desarrollo orientado a objetos

Cada paso del proceso transforma algunas entradas para generar una salida diferente,

comenzando en un alto nivel de abstracción hasta llevarlo a un nivel de detalle que

finalmente representa la solución del problema.



3.3.2. Modelos

Los pasos para construir el modelo de objetos son los siguientes:

1. Identificación de objetos y/o clases.

2. Crear un diccionario de datos.

3. Identificación de las asociaciones y agregaciones entre los objetos.

4. Identificación de atributos y enlaces.

5. Organización y simplificación de las clases empleando herencia.

6. Verificación de las vías de acceso necesarias para llevar a cabo las probables

consultas.

7. Realizar las iteraciones necesarias para el refinamiento del modelo.

8. Agrupar las clases en módulos.

Modelo de objetos = Diagrama de modelo de objetos + diccionario de datos.

Diagrama de clases

En él se describen las clases que se descubrieron para el sistema analizado en términos

del dominio del problema. Además se especifican los atributos y operaciones que

distinguen a cada una de las clases y las relaciones con las que podemos conocer su

responsabilidad en el sistema.

Figura 3.15. Nombre Clase

Dentro del diagrama de clases, una clase se representa mediante un rectángulo donde

pueden existir tres separaciones, en la primer parte se coloca el Nombre de la clase, en la

segunda y tercera parte se pueden agregar los atributos y las operaciones, pero sino se

desea agregar ninguno de ellos, es porque no son tan importantes para la comprensión

del sistema, entonces el rectángulo solo se queda con el nombre de la clase.

Modelo dinámico = Diagrama de estados + diagrama global de flujo de sucesos.

Escenario:

Es la representación escrita de los casos de uso y de la interacción de los actores con

ellos para especificar el propósito del sistema.



Figura 3.16. Escenario

Diagramas de estados: Relaciona sucesos y estados. Un diagrama de estados se

representa mediante estados, transiciones, condiciones y acciones.

Estados: Los estados representan las respuestas de los objetos a varios sucesos en

determinado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado del

objeto. Se representan mediante cuadros redondeados que contienen un nombre.

Transiciones: Se representan mediante flechas que salen del estado receptor hasta él y

el nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dicha

transición, cada transición que sale de un estado corresponde a un suceso distinto, lo cual

indica que no deben de existir sucesos duplicados dentro de un estado.

Condiciones: Una condición se puede pensar como una protección en las transiciones,

debido a que si se cumple dicha condición la transición se dará y podrá pasar el objeto de

un estado a otro, si dicha condición no se cumple inclusive podría pasar a otro estado

mediante otra transición o quedarse en el estado receptor hasta que la condición se

cumpla.

Acción: Es una operación que va asociada a un suceso y se representa mediante una

barra “/” y el nombre de la acción, después del nombre de la transición.

Modelo Funcional = Diagrama de flujo de datos + restricciones. Mediante el modelo

funcional se puede observar los resultados que se tienen de un cálculo de valores,

especificando solamente entradas y salidas de los valores, mas no como son calculados

estos. El modelo funcional consta básicamente de diagramas de flujo de datos. Los

diagramas de flujo de datos son grafos que muestran el flujo de valores de datos a través

de procesos los cuales modifican dichos valores para transformarlos en otros. Los

diagramas de flujo están compuestos de:

Procesos

Flujos de datos

Actores

Almacenes



Procesos: se representan mediante una elipse, los procesos tienen como entrada datos,

los cuales serán transformados, por lo cual un proceso es visto como un método de una

operación aplicada a una clase de objetos.

Figura 3.17. Proceso

Flujo de datos: un flujo de datos conecta la salida de un proceso a la entrada de otro. Se

representa en el diagrama por medio de una flecha, la cual puede llevar el nombre o el

tipo de dato. Además de trasladar los datos a otros procesos, los flujos de datos pueden

usarse para copiar un valor, realizar la composición de un agregado y así como su

inverso.

Actividad 1. Metodología para la generación de sistemas OO

La presente actividad tiene como propósito que reflexiones acerca de las metodologías

vistas hasta ahora cuál de ellas te parece la más adecuada a diseños orientado a objetos.

1. Retoma las lecturas de los temas 3.1. Booch, 3.2. OOSE y 3.3. OMT.

2. Identifica las metodologías y los modelos para diseñar con base en la Orientación a

Objetos.

3. Ingresa al foro y genera una nueva entrada.

3.4. UML

UML es una técnica desde en 1994 abarca aspectos de todos los métodos de diseño los

antecesores de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor



del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0

de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas

construidos para toda clase de industrias alrededor del mundo: hospitales, bancos,

comunicaciones, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

Mejores tiempos totales de desarrollo (de 50 % o más).

Modelar sistemas orientados a objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.

Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.

Mejor soporte a la planeación y al control de proyectos.

Alta reutilización y minimización de costos.


El lenguaje modelado unificado (UML) provee un sistema de arquitecturas trabajando con

objetos, análisis y diseño, con una buena consistencia del lenguaje para especificar,

visualizar, construir y documentar un sistema de software.

Esta especificación representa la convergencia de las mejores prácticas en la tecnología

de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos

derivado de las tres metodologías; (Booch, OMT y OOSE). Al conjuntar los métodos de

Booch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de éstos

y otros métodos.

El UML da la idea que lo que se está haciendo, se realiza con métodos existentes. Los

objetivos que se fijaron al desarrollar el UML fueron los siguientes:

Proporcionar a los usuarios un Lenguaje de Modelado Visual de tal forma que sea

posible intercambiar información de los modelos.

Proporcionar mecanismos de extensibilidad y especialización para ampliar los

conceptos básicos.

Ser independiente de un lenguaje en particular y del proceso de desarrollo.

Proporcionar bases formales para la comprensión del Lenguaje de Modelado.

Integración en una mejor práctica.

El UML es un lenguaje de modelado que incorpora a la comunidad orientada a objetos el

consenso de los conceptos de modelado básico y permite desviaciones, las cuales se



expresan en términos de mecanismos de extensión. Es un conjunto preciso que consiste

en la definición de la semántica y notación del UML, definiendo también cómo se maneja

el Lenguaje de Especificación de Objetos.

Partiendo del hecho que el ser humano requiere de modelos para manejar sistemas

complejos, y en cuanto más complejos se vuelven los sistemas, es necesario tener

mejores técnicas de modelado. El contar con una metodología universal para el desarrollo

de sistemas de software es de gran beneficio en la construcción de todo tipo de sistemas.

Disponer de buenos modelos facilita la comunicación entre equipos de trabajo en un gran

proyecto.

El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estándar, es

la herramienta ideal para atacar el ciclo de vida de un proyecto de software utilizando la

tecnología Orientada a Objetos.

El documento describe los mecanismos de la notación para la representación visual del

UML.

Existen básicamente cuatro constructores gráficos usados en la notación del UML; iconos,

símbolos de 2 dimensiones, uniones y cadenas.

Icono. Es una figura gráfica de tamaño y forma definida, éstos pueden aparecer dentro del

área de los símbolos, en la terminación de una unión, etc.

Símbolos de 2 dimensiones. Son de tamaño variable, pueden contener listas de cadenas

u otros símbolos. Las uniones se conectan a los símbolos de 2 dimensiones como

terminación de la unión sobre alguna parte del contorno de dicho símbolo.

Uniones. Son segmentos de línea con sus extremos terminados en algún símbolo de 2

dimensiones.

Cadenas. Representan conceptos, pueden existir como un elemento dentro de un símbolo

o dentro de un compartimiento de un símbolo, como elementos de una lista, como

etiquetas de un símbolo o unión, o como un elemento estándar dentro de un diagrama.

El documento está dividido en varios capítulos de acuerdo a los conceptos semánticos, o

por los diferentes tipos de diagramas. Cada capítulo está subdividido por los elementos

que conforman el diagrama, y para cada elemento se cuenta con las siguientes

secciones:

El nombre de la notación a describir

Semántica

Notación

Mapeo

Opciones de presentación



Cada punto cuenta con su propia descripción:

Nombre de la notación: Especifica el nombre de la notación

Semántica: Es un breve resumen de la semántica para dicho elemento.

Notación: Explica la representación dotacional de la semántica mediante un diagrama.

Obviamente para cada caso se utilizan un diagrama diferente que proporciona la

identificación de la semántica del grafo especificado.

Mapeo: Indica cómo la notación puede ser representada como información semántica. Es

decir qué tipo de diagrama se utiliza, con cuáles rutas se maneja y cómo trabaja una

estructura conectada con otra estructura dentro de un mismo diagrama. Dando así el

sentido de saber interpretar la notación que se presenta y con qué fin es utilizada.

Opciones de presentación: Son herramientas que pueden ser utilizadas para dar más

énfasis a la notación cuando ésta lo requiera dejándola más completa y estructurada. En

varios elementos esta sección no se presenta debido a que no tiene opciones de

presentación.

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)

El Lenguaje de Especificación de Objetos (Object Constraint Language, OCL), es un

lenguaje formal para expresar restricciones libres de efectos colaterales. Los usuarios del

Lenguaje Unificado para Modelado (UML) y de otros lenguajes, pueden usar el OCL para

especificar restricciones y otras expresiones incluidas en sus modelos. El OCL tiene

características de un lenguaje de expresión, de un lenguaje de modelado y de un lenguaje

formal.

El OCL es un lenguaje de expresión puro. Por lo tanto, garantiza que una expresión OCL

no tendrá efectos colaterales; no puede cambiar nada en el modelo. Esto significa que el

estado del sistema no cambiará nunca como consecuencia de una expresión OCL, aun

cuando una expresión OCL puede usarse para especificar un cambio de estado, por

ejemplo, en una post-condición.

Todos los valores, de todos los objetos, incluyendo todos los enlaces, no cambiarán,

cuando una expresión OCL es evaluada, simplemente devuelve un valor.

El OCL no es un lenguaje de programación, por lo tanto, no es posible escribir lógica de

programa o flujo de control en OCL. No es posible invocar procesos o activar operaciones

que no sean consultas en OCL. Dado que el OCL es un lenguaje de modelado en primer

lugar, es posible que haya cosas en él que no sean directamente ejecutables.



Como el OCL es un lenguaje de modelado, toda consideración de implementación está

fuera de su alcance, y no puede ser expresada en el lenguaje OCL. Conceptualmente,

cada expresión OCL es atómica. El estado de los objetos en el sistema no puede variar

durante la evaluación.

OCL es un lenguaje formal donde todos los constructores tienen un significado

formalmente definido, la especificación del OCL es parte del UML. El OCL no pretende

reemplazar lenguajes formales existentes como VDM y Z.

El OCL puede ser usado con distintos propósitos:

Para especificar características estáticas sobre clases y tipos en un modelo de

clases.

Para especificar características estáticas de tipo para Estereotipos.

Para especificar pre y post-condiciones sobre Operaciones y Métodos.

Como lenguaje de navegación.

Para especificar restricciones sobre operaciones:

Dentro del documento Semántica del UML, el OCL es usado en la sección

reglas bien formuladas, como constantes estáticas sobre la meta-clase en la

sintaxis abstracta. En varios lugares también es usado para definir

operaciones „adicionales‟, que son tomadas en cuenta en la formación de

reglas.

Las expresiones OCL pueden ser parte de pre-condiciones o post-condiciones, que son

Restricciones estereotipadas con «pre-condition» y «post-condition» respectivamente.

Las pre-condiciones o post-condiciones se aplican tanto a Métodos como a Operaciones.

Actividad 2. Cuadro comparativo de las diferentes metodologías

La presente actividad tiene la finalidad de que apliques cada uno de los conceptos

básicos de las metodologías de diseño vistas hasta ahora y además, que investigues las

fechas en las que implementaron dichas metodologías.

1. Investiga las fechas en que fueron implementadas las metodologías OO.

2. En un archivo de texto, elabora un cuadro comparativo donde incluyas las

características de cada una de las metodologías OO y la fecha en que fueron

implementadas.



3. Guarda la Actividad con el nombre ADOO_U3_A2_XXYZ donde XX es apellido(s) .y

YY es tu nombre(s).


Autoevaluación


unidad 3 del curso, es necesario que resuelvas la autoevaluación. Recuerda que es muy

importante leer cuidadosamente los planteamientos indicados y elegir la opción adecuada

para cada uno.

Evidencia de aprendizaje. Cuadro comparativo de los métodos de

modelado

Como parte de la evaluación de esta unidad, lleva a cabo la siguiente actividad cuyo

propósito es conceptuar el proceso.

1. En un archivo de texto elabora un cuadro comparativo de los diagramas que son

utilizados en cada uno de los modelos revisados en a lo largo de la unidad.

2. Al final del documento, redacta una conclusión donde expreses cuáles serían los

modelos más adecuados a utilizar en cada caso.

3. Consulta la Escala de Evaluación.

4. Guarda la evidencia con el nombre DOO_U3_EA_XXYY donde XX es tu apellido(s) y

YY tu nombre(s).


* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tu

Facilitador(a), podrás enviar una segunda versión de tu actividad.



Autorreflexiones



presente, a partir de ellas, debes elaborar tu Autorreflexión en un archivo de texto llamado


Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 3 del curso. A lo largo de ésta se recordaron las metodologías de

diseño para la generación de Sistemas Orientados a Objetos, tales como: Boosh, OOSE,

OMT, en cada uno de ellos se vio una breve introducción y su modelo. Por último el origen

de la metodología UML, la cual fue a través del OCL.


acaban de mencionar no te sean familiares, o no los recuerdes, de no ser este tu caso, ya

estás preparado(a) para seguir con la unidad 4, en donde continuarás con El diseño

orientado a objetos con UML, a través de la representación de objetos y clases con

diagramas y documentación para el diseño del software con UML, en dichos diagramas se

manejarán casos de uso, escenarios del caso de uso, diagramas de actividades,

secuencial, de clase y de gráfico de estado. Todo ello con el fin de obtener el prototipo

final al terminar el curso de Análisis y Diseño Orientado a Objetos.

Para saber más

En el siguiente documento encontrarás un ejemplo real de análisis aplicado al diseño de

un sistema escolar:

Desarrollo de un sistema de administración escolar académica para la escuela

“Cristóbal Colón” bajo plataforma web:

http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf

http://bibdigital.epn.edu.ec/bitstream/15000/3823/1/CD-3595.pdf



Fuentes de consulta

Booch-Grady (2009) Análisis y Diseño Orientado a Objetos con aplicaciones.


Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: Addison Wesley

Graham, I. (2002) Métodos Orientados a Objetos México: Addison Wesley/Díaz de

Santos.

Jacobson, I. (1992) Object-Oriented Software Engineering A Use Case Driven

Aproach México: Addison-Wesley

James, R., Blaha, M., Premerlani, W. & Eddym, F. (1990) Object Oriented

Modeling and Design. México: Pretice Hall.

Larman, C. (2004) Applying UML and Patterns An Introduction to object-Oriented

Analysis and Design México: Prentice Hall

Martin, J. & Odell, J. (1990) Análisis y Diseño Orientado a Objetos México:

Prentice Hall Iberoamericana.

Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML

México: Addison Wesley

Wirfs, R. & Wiener, L. (1990). Designing Object Oriented Softwarem. México:

Pretince Hall.



Unidad 4. Diseño orientado a objetos con UML (Lenguaje Unificado de

Modelado)


El lenguaje unificado de modelado (UML) brinda un sistema de trabajo con objetos,

basado en el análisis y diseño, con una consistencia del lenguaje para especificar,

construir y documentar un sistema de software.

Esta especificación representa la convergencia de las mejores prácticas en la tecnología

de la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetos

derivado de las tres metodologías (Booch, OMT y OOSE).

El UML es un lenguaje de modelado que integra a la comunidad orientada a objetos los

conceptos de modelado básico y permite desviaciones, las cuales se expresan en

términos de mecanismos de extensión. Es un conjunto preciso que consiste en la

definición de la semántica y notación del UML, definiendo también cómo se maneja el

Lenguaje de Especificación de Objetos.

Propósito

Con el uso constante de UML se podrá lograr una mejor comprensión entre los negocios y

los requerimientos del sistema y los procesos que se deben hacer para que se cumplan

éstos. En cada paso el sistema se define de manera más clara y precisa.

Así, al terminar el análisis y diseño se tienen de forma precisa y detallada las

especificaciones de clases y objetos, evitando el costo de una mala planeación en el

comienzo.


Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos mediante el

método de modelado UML.



4.1. Representación de objetos y clases con UML

En el diseño orientado a objetos todo se presenta través de objetos y clases. Por lo

general cuando se diseña una clase no es necesario mostrar todos los atributos ni todas

sus operaciones, basta con mostrar los subconjuntos más relevantes para organizarlos.

Un objeto, como recordarás, es la unidad mínima en la representación de algo real, y una

clase es un objeto con atributos y métodos o comportamientos.

4.1.1. Representación de clases con UML

Clases. Una clase es representada por medio de un marco subdividido en tres niveles: En

el primer nivel se muestra el nombre de la clase, el siguiente presenta los atributos y en el

último nivel se incluyen las operaciones.

Una clase puede representarse de forma esquemática con los atributos y operaciones

suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la

siguiente figura se ve cómo una misma clase puede representarse a distinto nivel de

detalle, según interese, y según la fase en la que se esté.



Figura 4.1. Representacion de clases con diferentes tipos de detalles

4.1.2. Representación de objetos con UML

Objetos. El objeto es representado de forma similar que una clase. En la parte superior

del marco aparece el nombre del objeto junto con el nombre de la clase, subrayados.

El siguiente ejemplo muestra la sintaxis: nombre_del_objeto: nombre_de_la_clase. Puede

representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la

clase.



Figura 4.2. Representación de objeto sin nombre

Actividad 1. Representación de clases y objetos con UML

Con el fin de reflexionar sobre la asignatura, en el foro: Cómo representar clases y

objetos con UML construirás un concepto propio sobre la mejor manera de representar

clases y objetos con UML, tomando en cuenta los temas abordados con anterioridad y los

comentarios de tus compañeros.

1. Recupera lo sustancial de las lecturas del tema 4.1. Representación de objetos y

clases con UML.

2. Identifica la forma más óptima para representar diferentes objetos dados por tu

Facilitador(a).

3. Ingresa al foro y genera una nueva entrada.



4.2. Diagramas y documentación para el diseño del software con UML

Los diagramas se utilizan para representar diferentes perspectivas de un sistema, de

forma que un diagrama es una proyección del propio sistema

El diseño de modelado UML proporciona un amplio conjunto de diagramas que

normalmente se usan en pequeños subconjuntos para poder representar las vistas

principales de la arquitectura de un sistema.

Los seis diagramas de UML que más se utilizan son:

1. Diagrama de caso de uso: describe cómo se usa el sistema; es ideal para comenzar.

2. Escenario de caso de uso (aunque técnicamente no es un diagrama), es una

descripción verbal de las excepciones.

3. Diagrama de actividades, muestra el recorrido de las actividades.

4. Diagramas de secuencias, muestran el orden de actividades y las relaciones de las

clases.

5. Diagramas de clases, muestran las clases y las relaciones.

6. Diagramas de gráfico de estado, muestra las transiciones de estado. Cada clase podría

crear un diagrama de gráfico de estado.

La siguiente figura muestra cómo se relacionan:



Figura 4.3. Conjunto de diagramas UML (Kendall & Kendall, 2005: 665)

4.2.1. Casos de uso

Un Diagrama de casos de uso muestra la relación entre los actores y los casos de uso del

sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su

interacción externa.

El caso de uso es la descripción de las secuencias de acciones recíprocas entre dos o

más objetos que se producen entre un actor y el sistema, cuando el actor usa el sistema

para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y

se representa en el Diagrama de casos de uso mediante una elipse con el nombre del

caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que

el actor desea llevar a cabo usando el sistema.

Los casos de uso son la parte realmente útil del documento que describe el caso de uso,

ya que en este documento se explica la forma de interactuar entre el sistema y el usuario.



En los casos de uso, la palabra uso se utiliza como sustantivo en lugar de verbo. Un

modelo de caso de uso muestra lo que hace un sistema sin describir cómo lo hace,

muestra como si tuviera un usuario fuera del sistema, mostrando los requerimientos y se

puede hacer usando los objetos y sus interacciones para derivar comportamiento del

objeto, atributos y relaciones.

Los actores dentro del modelado UML son aquellos que interactúan con el sistema a

desarrollar. Las precondiciones son los hechos que se han de cumplir para que el flujo de

evento se pueda llevar a cabo. El flujo de eventos corresponde a la ejecución normal y

exitosa del caso de uso. Los flujos alternativos son los que permiten indicar qué es lo que

hace el sistema en los casos menos frecuentes e inesperados. Por último, las

poscondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se ha

ejecutado correctamente.

El diagrama de caso de uso contiene el actor y símbolos de caso de uso, y además las

líneas de conexión. Los actores se refieren a una situación de un usuario del sistema, por

ejemplo un actor podría ser cliente.

Los actores dan o reciben los datos del sistema. Los actores secundarios ayudan a

mantener el sistema en ejecución o proporcionan ayuda, como las personas que operan

el centro de atención telefónica, los empleados(as) de ventanilla, etcétera.

Un caso de uso ilustra a los desarrolladores un panorama de lo que quieren los usuarios.

No tiene detalles técnicos o de implementación.

Un caso de uso se compone de tres elementos: un actor, para comenzar el evento; el

evento, que activa un caso de uso; y el caso de uso, que desempeña las acciones

activadas por el evento.



Los casos de uso documentan un solo evento. Un caso de uso se nombra con un verbo y

un sustantivo. Las relaciones son el comportamiento y se usan para conectar a un actor,

y hay cuatro tipos básicos:

En la imagen, por el tipo de flechas, se muestran los cuatro tipos: Comunica, Incluye,

Extiende y Generaliza.

Al hacer el diagrama del caso de uso hay que pedir todo lo que los usuarios quieren que

el sistema haga para ellos, es decir, mostrar los servicios que se deben proporcionar.

En las fases iniciales ésta podría ser una lista parcial que se extiende en las últimas fases

del análisis. Usa los siguientes lineamientos:

Revisar las especificaciones para establecer los actores.

Identificar los eventos y hacer los casos de uso.

Revisar el caso de uso para determinar el flujo de los datos.



Figura 4.4. Ejemplo de caso de uso de matriculación de estudiante (Kendall & Kendall,

2005: 669)

La figura muestra un caso de uso de una matriculación de un estudiante. Agregar un

estudiante incluye verificar la identidad de éste.

El caso de uso Comprar libro de texto extiende el caso de uso Matricularse en la clase y

podría ser parte de un sistema para matricular a los estudiantes de un curso en línea.

Pareciera como si el caso de uso Cambiar información del estudiante fuera una

característica menor del sistema y no se debiera incluir en el diagrama de caso de uso,

pero debido a que esta información cambia con frecuencia, la administración tiene un

interés sutil en permitir a los estudiantes cambiar su propia información personal. El hecho



de que los administradores juzguen esto como importante no solo justifica, sino que exige

que el estudiante pueda cambiar su información.

A los estudiantes no se les permitiría cambiar su promedio de calificaciones, cuotas a

pagar y otra información. Este caso de uso también incluye el caso de uso Verificar

identidad, y en esta situación, significa que el estudiante tiene que introducir una clave de

usuario y contraseña antes de acceder al sistema. Ver información del estudiante permite

a los estudiantes visualizar su información personal, así como también los cursos y

calificaciones.

Los diagramas de caso de uso son un buen punto de partida, pero se necesita una

descripción más completa de ellos para su documentación.

Figura 4.5. Cuatro tipos de relaciones (Kendall & Kendall, 2005: 667)



4.2.2. Escenarios del caso de uso

Cada caso de uso tiene una descripción como escenario del caso de uso, el cual

representa un caso en el que hay flujo de eventos y rutas para el comportamiento.

No hay un formato establecido, pero se deben considerar tres puntos importantes:

1. Identificadores e iniciadores de caso de uso.

2. Pasos desempeñados.

3. Condiciones, suposiciones y preguntas.

Este podría ser el caso de uso (use case) de escribir un mensaje en un foro.

Nombre: Crear mensaje foro

Autor: Juan Pérez

Fecha: 28/03/2011

Descripción:

Permite crear un mensaje en el foro de discusión.

Actores:

Usuario de Internet firmado.

Precondiciones:

El usuario debe haberse firmado en el sistema.

Flujo Normal:

1. El actor pulsa sobre el botón para crear un nuevo mensaje.

2. El sistema muestra una caja de texto para introducir el título del mensaje y una

zona de mayor tamaño para introducir el cuerpo del mensaje.

3. El actor introduce el título del mensaje y el cuerpo del mismo.

4. El sistema comprueba la validez de los datos y los almacena.

Flujo Alternativo:

1. El sistema comprueba la validez de los datos, si los datos no son correctos, se

avisa al actor de ello permitiéndole que los corrija.



Poscondiciones:

El mensaje ha sido almacenado en el sistema.

Ejemplo de caso de uso (Gracia, J., 2003: 1)

Un escenario del caso de uso, es una instancia expresada en el caso de uso.

Figura 4.6. Escenario de caso de uso

4.2.3. Diagramas de actividades

Son un tipo especial de diagramas de estado que se centra en mostrar el flujo de

actividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámica

de un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando el

flujo de control entre objetos.

Un diagrama de actividades muestra el flujo de actividades. Las actividades producen

finalmente alguna acción, que está compuesta de ejecutables que producen un cambio en

el estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otras

operaciones, envío de señales, creación o destrucción de objetos, o simples cálculos

(como la evaluación de una expresión).

Gráficamente, un diagrama de actividades es una colección de nodos y arcos.

Básicamente un diagrama de actividades contiene:



Estados de actividad. La representación de este estado está basada en un

rectángulo con las puntas redondeadas, donde el interior se representa una

actividad. El estado de actividad puede descomponerse en más sub-actividades

representadas a través de otros diagramas de actividades, estos estados pueden

ser interrumpidos y pueden tardar cierto tiempo en concluir. Adicional se pueden

encontrar elementos como: acciones de entrada y acciones de salida, tal como se

muestra en el ejemplo siguiente.



Figura 4.7 Diagrama de actividades para modelar una actividad (Alarcón, 2005: 73)

Estados de acción. Al igual que el estado de actividad, el estado de acción, está

basado en un rectángulo con las puntas redondeadas, donde en el interior se

representa una acción.

Transiciones. Las transiciones muestran el paso de un estado a otro, bien sea

estado de actividad o de acción. Esta transición se produce como resultado de la

finalización del estado del que parte el arco dirigido que marca la transición. Como

todo flujo de control debe empezar y terminar en algún momento, se puede indicar

esto utilizando dos disparadores de inicio y final.

Figura 4.8.Transición

4.2.4. Diagrama secuencial

Los diagramas de secuencia son un tipo de diagramas nombrados de interacción, y

constan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que se

pueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramas

de secuencia enfatizan el ordenamiento temporal de los mensajes, mientras que los

diagramas de colaboración muestran la organización estructural de los objetos que envían

y reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas de

colaboración sin pérdida de información, lo mismo ocurre en sentido opuesto.



Figura 4.9. Representación de clases en diagramas de secuencia

Un diagrama de secuencia en el modelado UML muestra una interacción ordenada según

la secuencia de cada evento. Muestra los objetos participantes en la interacción y los

mensajes que intercambian, ordenados según su secuencia en el tiempo. El eje vertical

representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes

en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los

mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de

arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones

de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o

activaciones a las que se refieren.

4.2.5. Diagrama de clase

Los diagramas de clase son utilizados para mostrar las relaciones entre las clases que

involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de

contenido.

Un diagrama de clases está compuesto por los siguientes elementos: clase, atributos,

métodos y visibilidad, y relaciones: herencia, composición, agregación, asociación y uso.

Elementos

Clase

Es la unidad básica que incluye toda la información de un Objeto, y un objeto es una

instancia de una clase. A través de ella podemos modelar el entorno en estudio: una

Casa, un Auto, una Cuenta Corriente, etc.

En UML una clase es representada por un rectángulo que posee tres divisiones:



Figura 4.10.Representación de una clase

Nivel Superior: Contiene el nombre de la Clase a utilizar.

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public).

Nivel Inferior: Contiene los métodos u operaciones, los cuales son la forma como

interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o

public).

Un ejemplo sobre el diagrama de clase:

Un Crédito que posee como característica:

Solicitud

Puede realizar las operaciones de:

Investigación de Crédito (investigación)

Análisis de crédito (análisis)

Y Entrega de crédito (entrega)

El diseño asociado es:

Figura 4.11. Representación de la clase cuenta



Atributos y Métodos:

Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el

grado de comunicación y visibilidad de ellos con el entorno, éstos son:

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es

decir, es accesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo

sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero

si podrá ser accesado por métodos de la clase además de las subclases que se deriven

(ver herencia).

Métodos:

Los métodos u operaciones de una clase son la forma en cómo ésta interactúa con su

entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase,

es decir, es accesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo

otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero

sí podrá ser accesado por métodos de la clase además de métodos de las subclases que

se deriven (ver herencia).

Actividad 2. Aplicación de diagramas

Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos de los

diagramas: casos de uso, actividades secuenciales y clase.

1. En un archivo de texto, realiza un listado en el que se mencionen cada uno de los tipos

de diagramas de casos de uso de actividades secuenciales y clase, incluye su definición

y en qué utilizarías cada uno de ellos de acuerdo al concepto entendido.



2. Guarda la Actividad con el nombre DOO_U4_A2_XXYZ. Sustituye las XX por las dos

primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por la

inicial de tu apellido materno.

3. Envía el archivo a tu Facilitador(a) a través de Tareas.

4.2.6. Diagrama de gráfico de estado

El Diagrama de Estados especifica la secuencia de estados que pasa el caso de uso, o

puede ser un objeto a lo largo de su vida. Se indican qué eventos hacen que se pase de

un estado a otro y cuáles son las respuestas y acciones que da por resultado.

Un diagrama de estados es un gráfico donde los nodos son estados y los arcos son

transiciones etiquetadas con los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su

interior, una transición se representa como una flecha desde el estado origen al estado

destino.

La caja de un estado puede tener uno o dos niveles: en el primer nivel aparece el nombre

del estado, el segundo nivel es opcional, y en él pueden aparecer acciones de entrada, de

salida y acciones internas.

Una acción de entrada aparece en la forma entrada/acción_asociada donde

acción_asociada es el nombre de la acción que se realiza al entrar en ese estado, cada

vez que se entra al estado por medio de una transición, la acción de entrada se ejecuta.

Una acción de salida aparece en la forma salida/acción_asociada, cada vez que se sale

del estado por una transición de salida la acción de salida se ejecuta. Una acción interna

es una acción que se ejecuta cuando se recibe un determinado evento en ese estado,



pero que no causa una transición a otro estado. Se indica en la forma

nombre_de_evento/acción_asociada.

Figura 4.12. Gráfico de estado de conexión a Internet

Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la

que hay un estado inicial de creación y un estado final de destrucción (finalización del

caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido

y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados

inicial y final no son estados, pues un objeto no puede “estar” en esos estados, pero nos

sirven para saber cuáles son las transiciones inicial(es) y final(es).

Actividad 3. Diseño de diagramas en UML

Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos delos

diagramas casos de uso, actividades secuenciales, clase y gráfico de estado.

1. En Word o Microsoft Visio diseña un ejercicio para cada uno de los diagramas,

suponiendo que se quiere diseñar un sistema para el control de ventas de una farmacia

en donde el usuario sería el despachador de la misma.

2. Describe cada uno de los diagramas y su contenido o justificación.

3. Guarda la Actividad con el nombre DOO_U4_A3_XXYZ. Sustituye las XX por las

dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por

la inicial de tu apellido materno.




Autoevaluación


unidad del curso, es necesario que resuelvas la actividad integradora. Recuerda que es

muy importante leer cuidadosamente los planteamientos indicados y elegir la opción

adecuada para cada uno.

Evidencia de aprendizaje. Diagramas UML

Como parte de la evaluación de esta unidad, realiza la siguiente actividad cuyo propósito

es conceptualizar el proceso de diagramación.

Instrucciones:

1. En un archivo de texto o Microsoft Visio diseña un ejercicio para cada uno de los

diagramas que revisaste en esta unidad, señalando el o los usuarios.

2. Describe cada uno de los diagramas y su contenido o justificación.

3. Consulta la Escala de evaluación.

4. Guarda la evidencia con el nombre ADOO_U4_EA_XXYZ. Sustituye las XX por las

dos primeras letras de tu primer nombre, la Y por la inicial de tu apellido paterno y la Z por

la inicial de tu apellido materno.

5. Envía el archivo a tu Facilitador(a) a través de Evidencia de aprendizaje, para recibir

retroalimentación.

Autorreflexiones



presente; a partir de ellas debes elaborar tu Autorreflexión en un archivo de texto llamado




Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 4 del curso. A lo largo de ésta se vieron conceptos de diseño

orientado a objetos con UML, cómo se representan los objetos y las clases, además de

cómo se hacen los diagramas para los casos de uso, escenarios del caso de uso,

diagramas de actividades, diagramas secuenciales, de clase y el gráfico de estado.


acaban de mencionar no te sean familiares, o no los recuerdes; de no ser éste tu caso, ya

habrás terminado tu curso de Análisis y diseño Orientado a Objetos, ¡FELICIDADES!

Para saber más

Insertar o crear un dibujo de Visio en otro programa:

Cómo insertar en Word un diagrama en Visio: http://office.microsoft.com/es-

mx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-office-

system-HA010198865.aspx

Fuentes de consulta

Alarcón, Raúl. (2005). Diseño orientado a objetos con UML. Grupo Eidos. Página

73.

Fowler, M. & Scott, K. (1999) UML GOTA A GOTA México: Addison Wesley.

Gracia, J. (2003) UML: Casos de Uso. Use case, Desarrollo de Software Orientado

a Objetos. Recuperado de:

http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php

http://office.microsoft.com/es-mx/visio-help/utilizar-visio-con-otros-programas-de-2007-microsoft-office-system-HA010198865.aspx



http://www.ingenierosoftware.com/analisisydiseno/casosdeuso.php



Kendall, J. & Kendall, J. (1990) Análisis y Diseño de sistemas. México: Prentice

Hall Iberoamericana.

Larman, C. (2004) Applying UML and Patterns an Introduction to object-Oriented

Analysis and Design. México: Prentice Hall.

Quatrani, T. & James, R. (1997) Visual Modeling with Rational Rose and UML

México: Addison Wesley.

04_PD_DS_DOO

Documents

Transcript of 04_PD_DS_DOO