04_PD_DS_DOO.pdf

7/16/2019 04_PD_DS_DOO.pdf

http://slidepdf.com/reader/full/04pddsdoopdf 1/96

Análisis y diseño orientado a objetosPrograma 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

7/16/2019 04_PD_DS_DOO.pdf




Í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

7/16/2019 04_PD_DS_DOO.pdf




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



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 aObjetos......................................................................................................................................... 46

7/16/2019 04_PD_DS_DOO.pdf






UNIDAD 3. METODOLOGÍAS DE DISEÑO PARA LA GENERACIÓN DESISTEMAS 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 (LENGUAJEUNIFICADO DE MODELADO) .............................................................................. 75


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

7/16/2019 04_PD_DS_DOO.pdf





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


7/16/2019 04_PD_DS_DOO.pdf




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 unprograma de computadora es una labor complicada, más aun si el programa que sequiere realizar está pensado en la metodología con orientación a objetos, la cual data delos 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 quese hace el análisis de un problema y sobre todo en el diseño de un programa que luegoserá pasado a código en un lenguaje específico para dar solución a la necesidad deautomatizar la información de la empresa.

Los conceptos de análisis y diseño orientado a objetos surgen a partir de los lenguajesmodernos 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 dedesarrollar y se obtienen mejores resultados.

En el análisis orientado a objetos se desarrollan una serie de modelos que nos orientansobre el software o lenguaje de programación a trabajar y así satisfacer un conjunto derequisitos definidos por el cliente. El modelo del análisis orientado a objetos ilustra lainformación, el funcionamiento y el comportamiento que llevará el flujo de la informacióndesde 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 comoanteproyecto para la construcción de software, convirtiéndolo así incluso en un softwarede fácil mantenimiento.

7/16/2019 04_PD_DS_DOO.pdf




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 seaprenda 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 talescomo herencia, polimorfismo, abstracción, etc. Dichos modelos han sido desarrolladospara que los sistemas sean más flexibles y el mantenimiento se vuelva sencillo. Mientrasque 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 mismosfundamentos. Las técnicas para el análisis y diseño Orientadas a Objetos todavía estánen 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 delas más usadas UML (Lenguaje Unificado de Modelado) por ser más eficiente en esteenfoque. Por lo anterior, en esta asignatura es necesario abordar una parte introductoriasobre 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 seutilizarán para poder llegar a la unidad 2, en la que se elaboran los papeles de trabajopara este tipo de análisis con orientación a objetos. Así pues las unidades 1 y 2 estánenfocadas al análisis, mientras que en las unidades 3 y 4 se abarca lo concerniente aldiseño orientado a objetos.

Desde el inicio de la primera unidad, el estudiante interactúa con las herramientas del aulavirtual, como foros y bases de datos. Posteriormente, se llevan a cabo trabajos, así comotambién se presentan actividades de investigación que complementan los contenidos, loque permite ejercitar y presentar sus evidencias de aprendizaje de los temas vistos encada 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: 100o Bien: 80o Regular: 60o Insuficiente: 50

7/16/2019 04_PD_DS_DOO.pdf




d. Propósito

El propósito general de la asignatura es realizar los diagramas que se requieren usandocomo base el análisis de un sistema con orientación a objetos mediante las herramientasde 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 cuatrimestrede la Ingeniería en Desarrollo de software. La materia sirve de apoyo para la asignaturade Programación orientada a objetos, además servirá como base para las asignaturas deProgramació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 objetos2. Requerimientos para el análisis del diseño orientado a objetos3. Metodologías de diseño para la generación de sistemas orientados a objetos4. 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 sudefinición y características, hasta las ventajas de hacer un buen análisis para lograr undiseño orientado a objetos, así como los conceptos básicos de modelos orientados aobjetos y lo referente al ciclo de vida del software. La unidad 2 trata sobre los papeles detrabajo para el análisis del diseño orientado a objetos, donde se revisa el levantamientode requerimientos, los estándares de especificación y los modelos del desarrollo desoftware. En la unidad 3 se exponen las diferentes metodologías para el diseño desistemas orientados a objetos: Booch, OOSE (Object-Oriented Software Engineering /Ingeniería de Software Orientado a Objetos), OMT (Object Modeling Technique / Técnicade Modelado de Objetos) y UML (Unified Modeling Language / Lenguaje Unificado deModelado). Finalmente, en la unidad 4, se trabaja el diseño orientado a objetos condiagramas 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 encualquier lenguaje con programación orientada a objetos.

7/16/2019 04_PD_DS_DOO.pdf




e. Competencia(s) a desarrollar

Competencia general:

Diagramar la estructura de un sistema orientado a objetos para su diseño con base en elaná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 devida, 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 objetosmediante el método de modelado UML.

f. Temario

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

1.1.1. Definición1.1.2. Características1.1.3. Ventajas

1.2. Identificación y conceptos básicos de modelos orientados a objetos1.2.1. Abstracción1.2.2. Encapsulamiento1.2.3. Modularidad1.2.4. Herencia1.2.5. Polimorfismo

1.3. Ciclo de vida del software y tipos de ciclos1.3.1. Definición1.3.2. Espiral1.3.3. Cascada1.3.4. Incremental

Unidad 2. Requerimientos para el análisis del diseño orientado a objetos2.1 . Levantamiento de requerimientos

7/16/2019 04_PD_DS_DOO.pdf




2.1.1. Introducción a los requerimientos2.1.2. Actividades para el levantamiento de requerimientos

2.2 . Documentación para levantamientos y especificaciones

2.2.1 Documentación2.2.2 Especificaciones

2.3 . Estándares de especificación2.3.1 Fases de la estandarización2.3.2 Análisis de restricciones

2.4 . Modelos del desarrollo de software2.4.1. Ágiles2.4.2. Predictivos

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

3.1.1. Introducción3.1.2. Modelos3.2. OOSE

3.2.1. Introducción3.2.2. Modelos

3.3. OMT3.3.1. Introducción3.3.2. Modelos

3.4. UML3.4.1. Introducción3.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 UML4.1.2. Representación de objetos con UML

4.2. Diagramas y documentación para el diseño del software con UML4.2.1. Casos de uso4.2.2. Escenarios del caso de uso4.2.3. Diagramas de actividades4.2.4. Diagrama secuencial4.2.5. Diagrama de clase

4.2.6. Diagrama de gráfico de estado

7/16/2019 04_PD_DS_DOO.pdf




g. Metodología de trabajo

El aprendizaje basado en la resolución de problemas es una metodología en la que sepresentan 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ácticalos conocimientos y procedimientos para promover el reforzamiento de lo aprendido o laresolución de dudas, así como el aprendizaje significativo, al comprobar los elementosteó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 losestudiantes, b) foros que sirven como base para participar en temas propuestos yobtener un mayor conocimiento acerca de los temas de cada unidad.

La realización de actividades formativas, entre las que destacan: tareas en las quese analiza el tema y se selecciona un ejemplo u otras en las que dado un ejemploespecifico se pide entregar documentación a requerimientos, también elaborar secuencias de tiempo investigaciones y diseñar diagramas como parte final para laaplicación del conocimiento adquirido.

La construcción del portafolio de evidencias (e-portafolio), el cual consta de laelaboración de mapas mentales para evidenciar el conocimiento adquirido,

levantamientos de requerimientos, cuadros sinópticos y diseño de diagramas conproblemas relativos a los temas abordados en cada una de las unidades queintegran la asignatura, que reflejen la utilización de los conocimientos adquiridos a lolargo de ésta.

La realización de actividades de autoevaluación que den cuenta del grado deaprendizaje adquirido y refuercen los conocimientos.

h. Evaluación

En el marco del Programa ESAD, la evaluación se conceptualiza como un procesoparticipativo, sistemático y ordenado que inicia desde el momento en que el estudianteingresa 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 activadel estudiante, así como una comunicación estrecha con su Facilitador(a) para que puedaevaluar objetivamente su desempeño, para lo cual es necesaria la recolección de

7/16/2019 04_PD_DS_DOO.pdf




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 laretroalimentación permanente es fundamental para promover el aprendizaje significativo yreconocer el esfuerzo. Es requisito indispensable la entrega oportuna de cada una de lastareas, actividades y evidencias, así como la participación en foros y demás actividadesprogramadas en cada una de las unidades, y conforme a las indicaciones dadas. Lacalificación se asignará de acuerdo con la rúbrica establecida para cada actividad, por loque 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óncontinua

Interacciones individuales ycolaborativas

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ínimaindicada 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.

7/16/2019 04_PD_DS_DOO.pdf




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 primeraunidad se expondrán los principios fundamentales de un buen análisis para hacer uncorrecto 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, conalgunos 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 sepasdarle 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 estainformació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 lasnecesidades 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 dediscusión general, el cual fue creado con la finalidad de que te presentes con tuscompañeros y comentes cualquier asunto relacionado con la asignatura; en él, conocerása tus compañeros de grupo y entre todos podrán apoyarse para resolver dudas,inquietudes, externar comentarios, etcétera.

7/16/2019 04_PD_DS_DOO.pdf




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 softwarecapaz de cubrir con las necesidades esenciales del usuario final, y su diseño se enfocaen los objetos.

El análisis orientado a objetos y su diseño se basa en definir una serie de actividadesrelevantes al problema que se va a resolver, en donde son comúnmente utilizadas lasoperaciones y atributos asociados. Para cumplir con esto se deben tener en cuenta lassiguientes tareas:

1.- Debe de existir una comunicación sobre los requisitos básicos del usuario ya queserá 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 esinherentemente poco acoplada. Además los sistemas orientados a objetos son másfáciles de adaptar y escalables.

El enfoque realizado sobre el desarrollo orientado a objetos no debe implicar hacer lastareas diferentes del enfoque clásico de desarrollo de software puesto que sedesarrollan actividades similares en un proceso evolutivo.

El modelo orientado a objetos tiene como característica el hecho de que un elementodel 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 cotidianosen el AOO, ya que son parte de su vocabulario.

Los conceptos fundamentales que llevan a un diseño de alta calidad son igualmenteaplicables a sistemas desarrollados usando métodos orientados a objetos. Por esa

7/16/2019 04_PD_DS_DOO.pdf




razón, un AOO debe exhibir abstracciones de datos y procedimientos que conducen auna modularidad eficaz.

La gestión de un proyecto de software orientado a objetos por lo general tieneactividades 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 dedisciplinas que desarrollan y modelan un software que facilita la construcción desistemas 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 confacilidad de mantenimiento y capaces de evolucionar con respecto a las necesidades yrequerimientos del usuario final.

1.1.1. Definición

Para comenzar a entender en qué consiste el análisis y diseño de software orientado aobjetos, 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 yoperaciones de una clase.

Clase: Representa a una entidad que tiene un estado interno y un comportamientocaracterístico.

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

7/16/2019 04_PD_DS_DOO.pdf




Los objetos tienen un estado interno y un comportamiento, el estado de undeterminado 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 tablade una base de datos o las variables de un programa estructurado, por ejemplo:La edad de una personaEl nombre de un animalLa altura de un edificioLa jornada de un trabajo

El comportamiento de un objeto se forma por el conjunto de operaciones que sepueden realizar. Cada una de esas operaciones recibe el nombre de método. Losmétodos podrían ser:

Dibujar un triángulo Asignar laboratorio de trabajo a un grupoPrestar un libro de la biblioteca

Cada objeto de una clase tiene sus propios atributos, que describen y caracterizan elestado en cada momento, y un conjunto de métodos, sobre los cuales ejecuta lasoperaciones que manifiesta su comportamiento.

El análisis orientado a objetos (AOO) construye un modelo orientado a objetos y a lasclases 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. Losobjetos existen por sí mismos, con una funcionalidad para invocar comportamientos deotros objetos. Por definición son modulares, es decir, pequeñas unidades lógicas decódigos independientes entre sí que se comunican entre ellas mediante mensajes en suconstrucción. Esto quiere decir que son entidades completas y, por lo tanto, tienden aser altamente reutilizables.

Las aplicaciones orientadas a objetos se constituyen sobre el paradigma de losmensajes a otros objetos.

Por lo general la mayoría de los programadores desarrolla sobre un lenguaje y soloutiliza su propio estilo de programación. Desarrollan sobre un paradigma forzado por ellenguaje que utilizan, tienden a no enfrentarse a métodos alternativos de resolución deun 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 deprogramación:

Orientada a procedimientos (Algoritmos).

7/16/2019 04_PD_DS_DOO.pdf




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 softwareque modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoquerepresenta 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 unanotación acordada, como por ejemplo, el lenguaje unificado de modelado (UML). ADOOaplica 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 deprogramas de computadora, sino que cubre sistemas enteros de distinto tipo. Lasmetodologías de análisis y diseño más modernas son casos de uso guiados a través derequerimientos, diseño, implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usadoen 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 quehacer para desarrollar un programa OO y se identifican los objetos, transformándolos enentidades y operaciones para asociarlos con el problema a resolver. En el diseño, losobjetos se relacionan con la solución del problema. Finalmente, en la programación sehace 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 sonsimilares y están definidos en su clase común.

De tal modo, los sistemas deben estar funcionando siempre de manera correcta, sucomplejidad a veces es tan grande que el mismo ser humano o su capacidad intelectualse ve excedida, por lo que resulta imposible comprenderlo en su totalidad por una solapersona.

Así, el software es complejo de forma innata, es una característica esencial de él. Escomplejo 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

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

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

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

7/16/2019 04_PD_DS_DOO.pdf




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

1. El problema presenta tantos requisitos que compiten entre sí o se contradicen, yesas contradicciones existen porque los usuarios no saben expresar sus necesidadesde forma clara para que las otras personas que participan en el proyecto lo puedanentender.

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 puededesecharse y reemplazarse por uno nuevo cada vez que los requisitos cambian, debeevolucionar, 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 elementode software anticuado y decadente.

4. La principal tarea del grupo de desarrollo es dar una ilusión de simplicidad para losusuarios 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 quese debe recurrir a la aplicación de varias técnicas de re-utilización de códigoexistente.

5. Debe también enfrentarse la existencia de miles de módulos separados y estoimplica 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 softwaresigue siendo una tarea muy laboriosa.

7. En algunos sistemas, una pequeña modificación en la entrada provoca unapequeña modificación en la salida. Mientras que en otros, y sobre todo de grantamaño, se percibe una explosión combinatoria que hace que la salida se modifiqueenormemente.

8. Se intenta diseñar los sistemas con una separación de intereses, de forma que elcomportamiento de una parte del sistema tenga el mínimo impacto en elcomportamiento 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 unaprueba a fondo exhaustiva por no tener las herramientas matemáticas ni intelectualespara un sistema no continuo.

10. Las consecuencias de la complejidad ilimitada. Mientras más complejo es elsistema, más abierto está al derrumbamiento total.

11. Crisis del software: ha existido tanto tiempo que debe considerarse normal. Escuando se pretende dominar la complejidad del sistema a un extremo que lleva al

7/16/2019 04_PD_DS_DOO.pdf




presupuesto a niveles excedentes y que transforman en deficiente al sistemarespecto 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 dediseñ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 losrequerimientos desde la perspectiva de las clases y objetos encontrados en elvocabulario del dominio del problema. El diseño orientado a objetos es un método dediseño que abarca el proceso de descomposición orientado a objetos y una notaciónpara representar ambos modelos (lógico y físico), como los modelos estáticos ydinámicos del sistema bajo diseño.

Dentro de las metodologías del análisis y diseño orientado a objetos, hay una variedadde métodos en la actualidad. Muchos de los métodos pueden ser clasificados comoorientados a objetos porque soportan de manera central los conceptos de la orientacióna 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 AUTORDiseño orientado aobjetos (DOO)

Grady Booch

Técnica de modelado deobjetos (TMO)

Rumbaugh

Análisis orientado aobjetos (AOO)

Coad/Yourdon

Jerarquía de diseñoorientada a objetos(JDOO)

ESA

Diseño estructurado Wasserman

7/16/2019 04_PD_DS_DOO.pdf




orientado a objetos(DEOO)

Análisis de sistemas

orientado a objetos(ASOO)

Shaler y Mellor, entreotros

Actualmente las metodologías más importantes de análisis y diseño de sistemasorientados 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 deproblema. Hoy en día, el ADOO puede que sea el único método que logre emplearse paraatacar 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 depersonal con entrenamiento adecuado o buenos entornos de desarrollo.

Lo interesante de la Programación Orientada a Objetos (POO) es que proporcionaconceptos y herramientas con las cuales se modela y representa el mundo real tanfielmente 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ñoprevio para realizar un buen programa, tomando en cuenta los temas abordados, realizalo 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 aobjetos

El análisis orientado a objetos es una forma de hacer frente a la comprensión y soluciónde problemas, usando modelos a partir de conceptos. La pieza fundamental es el objeto,el cual se combina en una sola entidad.

7/16/2019 04_PD_DS_DOO.pdf




Para dar énfasis sobre los conceptos en el análisis orientado a objetos, a continuación sedetallan los más básicos o utilizados con mayor frecuencia.

Objeto: Es una entidad bien definida, real o abstracta, que tiene sentido sobre el contextode 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, unarchivo 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 susatributos podrían ser su número de control, su nombre y su calificación. Se entiende quese 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 esaaplicació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 serequiere de algunas acciones y transformaciones: asignar calificación, leer nombre y leer número de control; estas acciones representan el comportamiento del objeto alumno. Enel caso de asignar calificación, leer nombre y leer número de control, se refieren atransformaciones, 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. Laselección de clases es arbitraria y depende de la aplicación.

Instancia: Se considera que cada objeto es una instancia de su clase. Toda clasedescribe un conjunto posiblemente finito de objetos individuales.

Identidad. Se refiere a que cada objeto conserva de manera inherente su propiaidentidad. 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 lasmismas dimensiones, textura, pero todos son diferentes, existen y tienen su propiaidentidad. Dos gotas de agua es otro ejemplo de la característica de identidad de losobjetos.

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 quees una instancia de la clase. Así que una clase, representa a un posible conjunto infinito

7/16/2019 04_PD_DS_DOO.pdf




de objetos individuales. Por ejemplo a todos los alumnos que aparecerán en la lista decalificaciones finales, los clasificamos en la clase Alumno. A todos los amigos queregistramos 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 ellobusca 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 quecuando queremos caminar lo haremos y punto.

Es la caracterización de un objeto de acuerdo a las propiedades que nos interesen en uninstante de tiempo. Las características escogidas son relativas a la perspectiva delobservador.

Figura 1.1. Abstracción.

1.2.2. Encapsulamiento

Cuando un objeto es encapsulado tenemos la libertad de saber qué información se hacepública o no, para ello podemos hacer privados e inaccesibles los datos de este objeto através otro previamente publicado.

Con esto logramos que los datos solo sean utilizados por su interfaz dejando de ladocómo está implementada, haciendo así, más fácil la utilización del mismo.

7/16/2019 04_PD_DS_DOO.pdf




Así pues, la manera de ocultar los detalles de la representación interna de un objeto espresentando 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 variosmódulos diferentes (ya sea en forma de clases, paquetes o bibliotecas), cada uno de elloscon un sentido propio.

Esta fragmentación disminuye el grado de dificultad del problema al que da respuesta elprograma, 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 realizaautomáticamente y se refiere a compartir atributos y métodos entre objetos que serelacionan de manera jerárquica durante un proceso de análisis de información.

Se percibe en la realidad como un agregado de objetos relacionados. Estasinterrelaciones, pueden verse como un conjunto de generalizaciones que se asimilan conel tiempo. Así pues, la herencia es el mecanismo fundamental de relación entre clases enla 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:

7/16/2019 04_PD_DS_DOO.pdf




Figura 1.3. Ejemplo de árbol de herencia

La capacidad de descomponer un problema o concepto en un conjunto de objetosrelacionados 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 otrasclases hijas o subclases.

1.2.5. Polimorfismo

“Mediante el denominado paso de mensajes, un objeto puede solicitar de otro objeto querealice una acción determinada o que modifique su estado. El paso de mensajes se sueleimplementar como llamadas a los métodos de otros objetos.

Desde el punto de vista de la programación estructurada, esto correspondería con lallamada a funciones” (García, s/f: 1)

Ahora bien, el polimorfismo es una característica de la orientación a objetos, que significaque un mismo método puede tener diferente manera de realizarse, en las diferentesclases 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 deprogramación automáticamente selecciona el método correcto para efectuar una ciertaacción o transformación sobre el objeto al que se aplica. Por ejemplo, si tenemos losobjetos bicicleta, carro, barco y les aplicamos la operación Mover, la acción se ejecuta demanera diferente para cada objeto. Otro ejemplo típico es el de los objetos de la claseFigura, digamos círculo, rectángulo, triángulo, apliquémosles la acción de Dibujar, cadauno de ellos tendrá su propio método Dibujar definido, ya que la acción debeimplementarse de manera diferente para cada objeto.

7/16/2019 04_PD_DS_DOO.pdf




Actividad 3. Ejemplos de sistemas

Esta actividad tiene como finalidad distinguir , en un primer acercamiento, cada uno delos 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 unade las etapas en los ciclos cascada y espiral incremental.

Ejemplo:Modelo de ciclo devida de zapatería

Etapa Descripción

Espiral Planificación En esta etapa enla zapatería se vaa…

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 ciclosLa metodología para el desarrollo de software tiene pasos establecidos en la realización yadministración de un proyecto para llevarlo a cabo con éxito. Para facilitar esto, se debedividir un gran proyecto en módulos más pequeños llamados etapas. Las acciones quecorresponden en cada una de ellas ayudan a definir entradas y salidas para cada una delas 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 puntualmenteuna 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 tienecapas claramente diferenciadas:

7/16/2019 04_PD_DS_DOO.pdf




Planificación: planteamiento detallado que los pasos a seguir durante eldesarrollo 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 sumomento.

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 fuediseñ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 seva desarrollando el sistema se hace un primer prototipo se presenta al cliente y sobre estese 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 decidimossi 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 elproyecto. En caso contrario incluimos los nuevos requerimientos solicitados por elcliente en la siguiente iteración.

7/16/2019 04_PD_DS_DOO.pdf




Figura 1.5. Espiral.

1.3.3. CascadaEl primer modelo de proceso de desarrollo de software que se publicó, se derivó deprocesos 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 aCascada. Cayendo de una a otra, las etapas de este modelo se transforman enactividades 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 losrequerimientos en sistemas hardware o software.3. Implementación y prueba de unidades. Durante esta etapa, el diseño del software selleva a cabo como un conjunto o unidades de programas.4. Integración y prueba del sistema. Los programas o las unidades individuales deprogramas se integran y prueban como un sistema completo para asegurar que secumplan los requerimientos del software.

7/16/2019 04_PD_DS_DOO.pdf




5. Funcionamiento y mantenimiento. Por lo general (aunque no necesariamente), estaes la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamientopráctico. El mantenimiento implica corregir errores.

Figura 1. 6. Cascada.

1.3.4. Incremental

Este modelo está basado en varios ciclos Cascada realimentados aplicadosrepetidamente, es decir que va incrementando las funcionalidades del programa. Serealiza construyendo por módulos que cumplen las diferentes funciones del sistema, loque permite ir aumentando gradualmente las capacidades del software. Desarrollar unmó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.

7/16/2019 04_PD_DS_DOO.pdf




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 queestá 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 aobjetos, en esta actividad debes proponer ejemplos que hagan referencia a cada uno de

ellos: abstracción, encapsulamiento, polimorfismo, modularidad, herencia, jerarquía ypaso 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 sistemasorientados a objetos.

2. De acuerdo con la definición que se revisó en los temas anteriores, inventa un ejemplode 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 estaprimera unidad del curso, es necesario que resuelvas la autoevaluación de la unidad.Recuerda que es muy importante leer cuidadosamente los planteamientos indicados yelegir la opción adecuada para cada uno.

Evidencia de aprendizaje. Mapa mental de los modelos orientados aobjetos

Como parte de la evaluación de esta unidad, llevarás a cabo esta actividad cuyo propósitoes organizar los conceptos abordados a lo largo de la unidad con la finalidad de tener presente las definiciones revisadas. Realiza lo siguiente:

7/16/2019 04_PD_DS_DOO.pdf




1. En un archivo de texto o Microsoft Visio, crea un mapa mental con las definiciones delos temas tratados durante la presente unidad. Recuerda que un mapa mental contienecuadros 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 quepuedes volver a enviar tu archivo tomando en cuenta las observaciones de tuFacilitador(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 llamadoDOO_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 conceptosgenerales 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, cuyopropósito fue dar un panorama para identificar un modelo orientado a objetos. De lamisma manera, se identificaron los ciclos de vida del software y los tipos de ciclos queexisten al diseñar un sistema orientado a objetos.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que seacaban de mencionar no te sean familiares o no los recuerdes, de no ser este tu caso, yaestás preparado(a) para seguir con la unidad 2, en donde abordarás los requerimientospara 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 quedeben 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 siguientesdirecciones electrónicas:

7/16/2019 04_PD_DS_DOO.pdf




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.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 GrawHill.

Bibliografía complementaria

Ciberaula (2010). Programación orientada a objetos. Recuperado el 10 de octubrede 2011 de: http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/

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

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 aobjetos. 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.

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

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










7/16/2019 04_PD_DS_DOO.pdf




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

Propósito

La especificación de requisitos es la primera fase de todo ciclo de vida o metodología dedesarrollo 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 lasalternativas de construcción del mismo que se nos planteen.

Estos dos objetivos principales se concretan en una serie de acciones a realizar, unastécnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, nosolo en el terreno informático) que un primer paso necesario para solucionar un problemaes tenerlo definido correcta y detalladamente. Esto implica dos cosas:

Es fundamental centrar la necesidad del cliente para poder definir el problema que se va aresolver, tratando de dejar claro lo que queda dentro y fuera del alcance del mismo. Eneste 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 lostipos 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 realizade manera repetitiva, progresiva, incremental. Por un lado, supone la planificación,

7/16/2019 04_PD_DS_DOO.pdf




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 elproyecto. 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 expresadospor 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 delequipo 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, atendiendosiempre a las opiniones del entrevistado. Él es nuestra fuente de información principal yde 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 sufuturo trabajo, expertos reticentes a compartir conocimientos.

Durante la realización de una entrevista lo habitual es la toma de notas, para redactar mástarde el informe de evaluación de la misma. Para la grabación en audio o en video espreceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta siesto va a interferir en la entrevista, haciéndole sentir incómodo. Pese a su costo, se vageneralizando el uso de videoconferencias para la realización de entrevistas remotas, conla 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 recabadapara 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 laentrevista, 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?

7/16/2019 04_PD_DS_DOO.pdf




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 haobtenido la Especificación de Requisitos. En ella se describe lo que el sistema nuevodebe 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. Consisteen 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 unformato gráfico, más fácil de manejar. Este formato hace que los requisitos seanentendibles 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 elsistema. 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 tareasque 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 senecesita almacenar.

Eventos. Son la parte dinámica de la aplicación. Muestran los aspectos del sistemaque cambian con el tiempo. Provocan la ejecución de la operación adecuada encada momento. Son los que activan la aplicación (la ponen en marcha) y propaganesa activación a lo largo de la aplicación, desencadenando la ejecución de otrasoperaciones. Los eventos llevan el control de la aplicación introduciendo eldinamismo necesario para su ejecución. Los eventos tienen mucha relación con lainterfaz de la aplicación. Porque a través de la interfaz se introducen los eventos.

7/16/2019 04_PD_DS_DOO.pdf




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, senecesitan los tres. En algunos sistemas predomina más uno que otro, pero siempre estánpresentes los tres.

Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es unarepresentación abstracta de la realidad. Por tanto, como resultado del análisis seobtendrán:

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

Modelo de Procesos: recoge qué funciones, actividades, tareas, acciones, deberealizar la aplicación y cómo manejar los datos.

Modelo de Datos: describe la información que maneja la aplicación, los datos quedebe almacenar. Y muestra cómo organizarla.

Modelo de Eventos: Indica en qué momento debe ejecutarse cada acción. Paraconstruir 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, lasrestricciones que se deben cumplir.

El diseño pretende obtener una solución óptima que cumpla todos los requisitos. Seorienta hacia la máquina, centrándose en cómo crear un sistema software que reúnatodas las necesidades y cumpla todas las restricciones.

El levantamiento de requerimientos incluye tres tipos de actividad:

7/16/2019 04_PD_DS_DOO.pdf




Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios paradeterminarse cuáles son sus requisitos. Esto a veces también se llama acopio delos 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 variasformas, tales como documentos de lenguaje natural, utilice los casos, historias delusuario, 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 unprograma orientado a objetos construirás un concepto propio, tomando en cuenta lostemas 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ñoOrientado 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 elproceso de ADOO y mantener los documentos necesarios para los desarrolladores y losusuarios. El esquema formal que debe tener una especificación de requisitos es elsiguiente:

1. Índice

2. Descripción del ámbito y alcance del proyecto3. Lista de usuarios participantes4. Descripción del sistema actual5. Catálogo (priorizado) de requisitos del sistema

a. Funcionalesb. No funcionales

i. Restriccionesii. De funcionamiento

7/16/2019 04_PD_DS_DOO.pdf




* Del sistema* Requisitos software* Requisitos hardware

iii. Manejo de excepciones6. Análisis de alternativas

a. Descripción de la alternativa 1b. Descripción de la alternativa 2c. Descripción detallada de la alternativa seleccionada

i. Modelo lógico de procesosii. Análisis costo-beneficioiii. 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 elanálisis. En la práctica es común describir los requerimientos en un documento, llamadoespecificación de requerimientos del software, su principal objetivo es de comunicar deforma efectiva los requerimientos, objetivos del dominio.

En primera instancia la documentación contiene la información que aporta el cliente queencarga la aplicación, contiene todos los registros de las reuniones de trabajo del grupode 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 unaforma única.

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

7/16/2019 04_PD_DS_DOO.pdf




• 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éncontiene las actas de las reuniones de trabajo del grupo de análisis, es necesario unsecretario que tome acta y es necesario aprobar el acta de cada reunión por todos losmiembros.

2.2.2. Especificaciones

Expresa las características esenciales de un objeto, las cuales distinguen al objeto uno deotro. A parte de distinguir los objetos también provee límites conceptuales, permitiendoque se disponga de las características de un objeto que se necesite.

El objetivo principal de las especificaciones, es en entregar una especificación derequisitos que ayuden a determinar de forma completa y correcta el diseño orientado aobjetos.

2.3. Estándares de Especificación

Las especificaciones del software determina el proceso de comprensión y definiciónsobre los servicios que se requieren del sistema y de identificación de las restricciones defuncionamiento y desarrollo del mismo. La ingeniería de requerimientos es un procesocrítico en el proceso del software, los errores en esta etapa originan problemasposteriores en el diseño e implementación del sistema.

En la siguiente figura se muestra el proceso de ingeniería de requerimientos. Ésteconduce a la producción de un documento de requerimientos, que es la especificación delsistema. Normalmente en este documento los requerimientos se presentan en dos nivelesde detalle. Los usuarios finales y los clientes necesitan una declaración de alto nivel delos requerimientos, mientras que los desarrolladores del sistema necesitan unaespecificación más detallada de éste.

7/16/2019 04_PD_DS_DOO.pdf




Figura 2.2

2.3.1. Fases de la estandarización

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

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 sistemapropuesto 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álisismás detallado.

2. Obtención y análisis de requerimientos. Es el proceso de obtener los requerimientosdel sistema por medio de la observación de los sistemas existentes, discusiones con losusuarios potenciales y proveedores, el análisis de tareas, etcétera. Esto puede implicar eldesarrollo de uno o más modelos y prototipos del sistema que ayudan al analista acomprender el sistema a especificar.

3. Especificación de requerimientos. Es la actividad de traducir la informaciónrecopilada durante la actividad de análisis en un documento que define un conjunto derequerimientos. En este documento se pueden incluir dos tipos de requerimientos: losrequerimientos del usuario, que son declaraciones abstractas de los requerimientos delcliente y del usuario final del sistema, y los requerimientos del sistema, que son unadescripción más detallada de la funcionalidad a proporcionar.

4. Validación de requerimientos. Esta actividad comprueba la veracidad, consistencia ycompletitud de los requerimientos. Durante este proceso, inevitablemente se descubren

7/16/2019 04_PD_DS_DOO.pdf




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 deforma estrictamente secuencial. El análisis de requerimientos continúa durante ladefinición y especificación, y a lo largo del proceso surgen nuevos requerimientos. Por lotanto, las actividades de análisis, definición y especificación se entrelazan. En losmétodos ágiles como la programación extrema, los requerimientos se desarrollan deforma incremental conforme a las prioridades del usuario, y la obtención derequerimientos 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 deentidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restricciónreduce los valores que una entidad puede tomar.

Restricciones entre objetos. Determina el estado en el cual los objetos sediferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina nopuede ser después de las 9:00, suponiendo que el horario de entrada al trabajo esa las 9:00.

Restricciones entre atributos de un objeto: Determina los atributos específicos deun objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombrecompleto y no apellido paterno, apellido materno y nombre.

Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objetodonde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumnono puede aumentar su número de control.

Las restricciones simples pueden situarse en el modelo de objetos, restriccionescomplejas 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.

7/16/2019 04_PD_DS_DOO.pdf




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 deespecificaciones de un análisis, diseña un programa con orientación a objetos haciendoun documento que sirva como base para conocer los requerimientos para diseñar unprograma para un salón de belleza.

1. Plantea una situación hipotética o ve a preguntar a un salón de belleza con elencargado o encargada acerca de qué le gustaría controlar por computadora (Obtención yanálisis de requerimientos).

2. En un archivo de texto escribe los requerimientos del usuario y del sistema, deacuerdo 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) yYY nombre(s).


2.4. Modelos del desarrollo del software

Las metodologías se centra en una serie de combinaciones de los modelos de procesogenéricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodología debedefinir con precisión los roles y actividades involucradas, junto con prácticas, guías deadaptación.

Habitualmente se utiliza el término “método” para referirse a técnicas, notaciones y guíasasociadas, 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 ladiversidad de propuestas y diferencias en el grado de detalle, información disponible yalcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notacionesutilizadas para especificar artefactos producidos en actividades de análisis y diseño,

7/16/2019 04_PD_DS_DOO.pdf




podemos clasificar las metodologías en dos grupos: Metodologías Estructuradas yMetodologías Orientadas a Objetos. Por otra parte, considerando su filosofía dedesarrollo, 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 deMetodologías Tradicionales (o peyorativamente denominada Metodologías Pesadas, oPeso Pesado). Otras metodologías, denominadas Metodologías Ágiles, están másorientadas a la generación de código con ciclos muy cortos de desarrollo, se dirigen aequipos de desarrollo pequeños, hacen especial hincapié en aspectos humanosasociados 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 particularmenteapropiadas en proyectos que utilizan para la implementación lenguajes de 3ra y 4tageneración.

Ejemplos de metodologías estructuradas de ámbito gubernamental: MERISE (Francia),MÉTRICA (España), SSADM (Reino Unido). Ejemplos de propuestas de métodosestructurados en el ámbito académico: Gane &Sarson, Ward &Mellor, Yourdon&DeMarcoe InformationEngineering.

Metodologías orientadas a objetos, va unida a la evolución de los lenguajes deprogramació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 yactualmente 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 deconseguir una unificación de sus métodos y notaciones, que posteriormente se reorienta aun objetivo más modesto, para dar lugar al UnifiedModelingLanguage (UML), la notaciónOO 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ónestructurada).

7/16/2019 04_PD_DS_DOO.pdf




2.4.1. Ágiles

Nuevas técnicas para aplicar las prácticas esenciales de la programación extrema ymétodos ágiles para desarrollar sistemas orientados a objetos se encuentre lametodología ágil. Es cuando el desarrollo de software es incremental (entregas pequeñasde software, con ciclos rápidos), cooperativo (cliente y desarrolladores trabajan juntosconstantemente con una cercana comunicación), sencillo (el método en sí mismo es fácilde 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 delosprincipios esenciales de la programación extrema, el modelado ágil agrega principios talescomo "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óndurante todo el proceso de desarrollo; llamadas también metodologías tradicionales oclásicas, donde se realiza una intensa etapa de análisis y diseño antes de la construccióndel sistema.

Todas las propuestas metodológicas antes indicadas pueden considerarse comometodologías tradicionales por el especial énfasis que presenta en cuanto a suadaptació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 omecánica. Tales disciplinas enfatizan que hay que planear antes de construir. Losingenieros trabajan sobre una serie de esquemas que indican precisamente qué hay que

7/16/2019 04_PD_DS_DOO.pdf




construir y cómo deben juntarse estas cosas. Muchas decisiones de diseño, como lamanera de controlar la carga sobre un puente, se toman conforme los dibujos seproducen. 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ónseguirá los dibujos. En la práctica los constructores se encuentran con algunosproblemas, pero éstos son normalmente poco importantes.

Como los dibujos especifican las piezas y cómo deben unirse, actúan como losfundamentos de un plan de construcción detallado. Dicho plan define las tareas quenecesitan hacerse y las dependencias que existen entre estas tareas. Esto permite unplan de trabajo y un presupuesto de construcción razonablemente predecibles. Tambiéndice en detalle cómo deben hacer su trabajo las personas que participan en laconstrucció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ásfácil de predecir. Una vez que tenemos el diseño, podemos planear la construcción. Unavez que tenemos el plan de construcción, podemos ocuparnos de la construcción de unamanera más predecible. En ingeniería civil la construcción es mucho más costosa ytardada que el diseño y la planeación.

Así el acercamiento de muchas metodologías es: queremos un plan de trabajo predecibleque 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 softwarede 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ñocomo el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisionessignificativas usando UML, podemos armar un plan de construcción y entonces podemosdar planes a los programadores como una actividad de construcción.

Pero aquí surgen preguntas cruciales. ¿Es posible armar un plan que sea capaz deconvertir 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 esteenfoque?

Todo esto trae a la mente más preguntas. La primera es la cuestión de cuán difícil esconseguir un diseño UML en un estado que pueda entregarse a los programadores. Elproblema con un diseño tipo UML es que puede parecer muy bueno en el papel, peroresultar seriamente fallido a la hora de la programación. Los modelos que los ingenierosciviles usan están basados en muchos años de práctica guardados en códigos

7/16/2019 04_PD_DS_DOO.pdf




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 losdiagramas 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ñadoresexperimentados se sorprenden a menudo cuando convierten dichos diseños en software.

Otro problema es el costo comparativo. Cuando se construye un puente, el costo delesfuerzo 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. Sesugiere que para un proyecto grande, sólo 15% del proyecto son código y pruebasunitarias, 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, r ealiza un cuadro comparativo de los modelos ágiles ypredictivos, 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) yYY nombre(s).


7/16/2019 04_PD_DS_DOO.pdf




Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en estaprimera unidad del curso, es necesario que resuelvas la actividad integradora. Recuerdaque es muy importante leer cuidadosamente los planteamientos indicados y elegir laopción adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para diseñar un programaOrientado a Objetos

Como parte de la evaluación de esta unidad, debes llevar a cabo una actividad cuyopropósito es conceptuar el proceso.

1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con losestándares para diseñar un programa con OO para el control de una papelería ymenciona 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 derequerimientos para el análisis orientado a objetos, comenzando con la parte delevantamiento 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 queespecificaciones debe cumplir considerando sus estándares, divididos en sus fases yanálisis de restricciones. Por último en esta unidad debes distinguir que modelos deldesarrollo de software se manejan y si son ágiles o predictivos.

7/16/2019 04_PD_DS_DOO.pdf




Es aconsejable que revises nuevamente la unidad en caso de que los temas que seacaban de mencionar no te sean familiares o no los recuerdes, de no ser este tú caso, yaestá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, talescomo Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la última unidad del cursode 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 paraprogramacionextrema.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 22de 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

http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis


http://www.programacionextrema.org/articulos/newMethodology.es.html

http://www.di.uniovi.es/~cernuda/pfc/aoo.pdf

7/16/2019 04_PD_DS_DOO.pdf




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 algunosconceptos que se definen a continuación.

Método. Es un conjunto de lineamientos y reglas, incluyendo los siguientescomponentes.

Conceptos de modelado. Permiten la captura de la semántica y el conocimientoacerca de un problema y su solución.

Modelo es una representación formal de un sistema con cierto nivel deabstracción. En las etapas de especificación de requerimientos y análisis el nivelde abstracción normalmente es alto, omitiendo detalles de implementación.

Meta modelo. Es un modelo que describe otros modelos, describe los conceptosdel 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 deinformació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 sepuede dibujar de diferentes maneras mediante el uso de diferentes símbolos,donde algunos de ellos pueden tener el mismo significado. Cada persona puedeadoptar su propio formato para describir sus diagramas.

Proceso de desarrollo iterativo. Representa una secuencia de pasos para laconstrucción e implementación de modelos. El proceso puede estar distribuido envarios 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 producidosy las etapas para producirlos. A alto nivel, describe el desarrollo del ciclo de vida ylas etapas de iteración dentro de él. A bajo nivel describe un esqueleto de trabajopara 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,

7/16/2019 04_PD_DS_DOO.pdf




mediciones de calidad, referencias cruzadas, reglas de consistencia y banderasrojas 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 nuevosdiseñadores puedan aprender, emulando programas que allí existen, mas bien,tratan de captar ideas de los diseñadores expertos. Actualmente existe unMovimiento 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 deellos. Por lo tanto, Los Patrones son resúmenes de casos de diseño basados en laexperiencia.

Reglas de Diseño. Son estados o propiedades que deberán llevarse a cabo uomitirse en un diseño o estrategias generales de diseño a utilizar. Tips y Reglas dededo. 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 losobjetos y las operaciones que sobre ella operan.

Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): unobjeto tiene sentido en estos métodos cuando exhibe un comportamientodiferencial respecto del resto delos objetos.

7/16/2019 04_PD_DS_DOO.pdf




En la tabla anterior se mezclan métodos de análisis y de diseño porque, pese a lo queanuncien sus autores o aun su mismo nombre, la distinción entre análisis y diseño sedifumina, aquí presentamos los más utilizados y que dieron origen al que actualmente seutiliza 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écnicade modelado de objetos) y UML (Unified Modeling Language / Lenguaje Unificado deModelado) las cuales nos servirán después de hacer un análisis para hacer un buendiseño apoyado con estas técnicas.

7/16/2019 04_PD_DS_DOO.pdf





Comparar las metodologías de diseño para la generación de sistemas orientados aobjetos mediante los diagramas con los métodos de modelado Booch, OOSE, OMTyUML.

3.1. Booch

Es una metodología que se utiliza en el análisis y diseño de software creada por Boochdurante su estancia en Rational Software Corporation.

El método BOOCH define modelos para describir un sistema, soportando el desarrolloiterativo e incremental. El método incluye diferentes diagramas según el enfoque que sele dé ya sea:

De clases De objetos De transición de estados De módulos De procesos

De interacción

3.1.1. Introducció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 unsistema 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 losmodelos del sistema, éstos reflejan "toda la verdad" sobre sus clases, relaciones y otrasentidades y cada diagrama representa una proyección de estos modelos. En el estadoestable, todos estos diagramas deben ser consistentes con el modelo y tambiénconsistentes entre ellos mismos.

7/16/2019 04_PD_DS_DOO.pdf




Dimensión lógica: Describe la existencia y significado de las abstracciones principales ylos 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 delcontexto 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ónló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 eldiseño físico de un sistema.4.- Diagramas de procesos: Muestran la asignación de procesos a procesadores en eldiseño físico de un sistema.

Dimensión dinámica: La semántica dinámica de un problema se expresa mediante lossiguientes diagramas:

1.-Diagrama de transición de estados: Muestra el comportamiento de cada instancia deuna 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 dediagrama.2.- Diagramas de interacción: Muestra el orden temporal en que se suceden los mensajesen un conjunto de objetos que representan un escenario. Están en el mismo contexto quelos diagramas de objetos.

3.1.2. Modelos

Diagramas de Clases

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

7/16/2019 04_PD_DS_DOO.pdf




La figura siguiente muestra el icono que se utiliza para representar una clase en undiagrama de clases. En ciertos diagramas de clases, es útil exponer algunos de losatributos y operaciones asociados con una clase:

Figura 3.1. Clase

Los atributos denotan una parte de un objeto agregado, durante el diseño expresan unapropiedad 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 losatributos 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 loshay).

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

Figura 3.2. Conexiones entre clases

7/16/2019 04_PD_DS_DOO.pdf




La asociación conecta dos clases y denota una conexión semántica, se etiquetan conexpresiones sustantivas, denotando la naturaleza de la relación.

La herencia denota una relación de generalización / especialización (una relación <<esun>>), y aparece como una asociación con una cabeza de flecha. La flecha apunta a lasuperclase, y el extremo opuesto de la asociación designa la subclase. La subclasehereda la estructura y comportamiento de su superclase. Las relaciones de herencia nopueden 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 alagregado, la clase que está en el otro extremo denota la parte cuyas instancias estáncontenidas por el objeto agregado.

La Utilización: denota una relación cliente / servidor y aparece como una asociación conuna circunferencia en el extremo que denota al cliente. En esta relación de alguna formael 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 deobjetos son los objetos y sus relaciones.

Objetos en la figura siguiente muestra el icono que se usa para representar un objeto enun diagrama de objetos. Al igual que en el diagrama de clases, también se puedenespecificar algunos atributos del objeto.

7/16/2019 04_PD_DS_DOO.pdf




Figura 3.4. Objeto

Relaciones entre objetos: los objetos interaccionan a través de sus enlaces con otrosobjetos, un enlace es una instancia de una asociación, al igual que un objeto es unainstancia 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 aexplicar 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

7/16/2019 04_PD_DS_DOO.pdf




Se utiliza un diagrama de módulos para mostrar la asignación de clases y objetos amó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 undiagrama 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 delas entidades.

Subsistema: Los subsistemas sirven para modularizar el modelo físico de un sistema. Unsubsistema 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 dependenciade compilación, representada por una línea dirigida que apunta al módulo respecto al cualexiste la dependencia. Las flechas denotan dependencias, la flecha sale del el iconodependiente.

Diagrama de procesos

Se usa un diagrama de procesos para mostrar la asignación de procesos a procesadoresen 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/odispositivos.

7/16/2019 04_PD_DS_DOO.pdf




Figura 3.7. Diagrama de procesos

El proceso de diseño orientado a objetos no puede describirse mediante reglas, aunqueestá bastante bien definido como para brindar un proceso predecible y repetible para unaorganizació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 formaeconó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).

7/16/2019 04_PD_DS_DOO.pdf




Modelo de diseño: refina el modelo de análisis y lo adapta a un ambiente deimplementación. Consiste de diagramas de interacción y diagramas de transiciónde estados.

Modelo de implementación: consiste en el código fuente de los objetosespecificados en el modelo de diseño.

Modelo de prueba: es llevado a cabo mediante la realización de pruebas al modelode implementación.

La idea básica de estos modelos es capturar el concepto inicial de todos losrequerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre elloses importante. Para ser posible el mantenimiento del sistema es también necesario quelos 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 desoftware haciendo una comparación con la industria de la construcción, contemplando lassiguientes 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ómola arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de laarquitectura 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 planestructurado de construcción y un plan de acción para su implementación .El diseñocreativo tomando como referencia una base arquitectónica es seguir paso a paso losmétodos y procesos con la asistencia de herramientas, para convertir los requerimientosdentro de una arquitectura viable para la construcción de un proyecto incluyendo lacreación de prototipos.

7/16/2019 04_PD_DS_DOO.pdf




Un aspecto importante durante el desarrollo del sistema, es considerar explícitamente elproceso de cambio.

Todos los sistemas cambian durante su ciclo de vida. Hoy en día el desarrollo de losnuevos métodos es conocer qué cambios son los principales en la parte global del ciclode 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 cambiosincorporándose en nuevas versiones.

La primera versión de un sistema representa una pequeña parte de una composicióndurante 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 radicaen que las entradas para cada etapa cambian en cada ciclo de vida.

Modelo de análisis. Especifica el comportamiento funcional del sistema bajoprácticamente circunstancias ideales y sin hacer alusión a un ambiente particular deimplementación.

Construcción. La primera actividad en la construcción consiste en la implementación delos detalles que conciernen a la arquitectura y construcción del plan, que es ir de unamayor abstracción a concretizar más el plan.

Diseño. Formaliza el modelo de análisis en términos del ambiente de implementación yespecifica la identidad de los bloques de construcción.

Prueba del sistema. Consiste en la verificación del trabajo de cada uno de los paquetesde 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 tomavarios años para su terminación. La especificación es seguida por el análisis, laconstrucció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 lacomprensión del sistema en cuanto a su funcionalidad se van agregando nuevasfunciones, de esta forma el sistema va creciendo.Sistema de desarrollo y metodología. Cuando se desarrolla un sistema grande esimportante conocer cómo cada uno de los pasos del método interactúa y cómo ellos

7/16/2019 04_PD_DS_DOO.pdf




compiten dentro del desarrollo del proceso. Se hace hincapié en la discusión entre elproceso de desarrollo y las ideas básicas que hay detrás del método lo que determina laselecció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 sidotomados en consideración. Se trabaja con 5 modelos:

1. El modelo de requerimientos: El objetivo es la captura de requerimientosfuncionales.

2. El modelo de análisis: El objetivo es dar al sistema una estructura de objetosrobusta y flexible a los cambios.

3. Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetosen 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 losrequerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre elloses importante. Para hacer posible el mantenimiento del sistema es también necesario quelos modelos sean tangibles.

Modelo de requerimientos Actores y Casos de UsoLa primera transformación hecha de la especificación de requerimientos para el modelode requerimientos consiste en:

Un modelo de caso de usoDescripción de la interfaceUn modelo en el dominio del problema

Figura 3.8. Modelo de caso de uso

7/16/2019 04_PD_DS_DOO.pdf




El modelo de caso de uso utiliza actores y caso de uso. Estos conceptos son usados paradefinir 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 lasnecesidades de cambio de información con el sistema. Dado que el actor representa laparte 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 elsistema, 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 limitacionesdel sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha sidodesarrollado 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 describeel estado interno del sistema.

Comportamiento: Especifica el comportamiento que adopta el sistema. Especificacuá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 deanálisis

7/16/2019 04_PD_DS_DOO.pdf




Figura 3.10. Tipos de objeto

Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis, sinembargo 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 elmodelo de requerimientos. Primero se crea el modelo de diseño que es un refinamiento yformalización del modelo de análisis. Al inicio del trabajo cuando se desarrolla el modelode 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 deanálisis debe ser visto como un modelo conceptual o lógico del sistema, y el modelo de

7/16/2019 04_PD_DS_DOO.pdf




diseño contiene el código, por lo cual el modelo de diseño deberá ser una representaciónde 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 deespacio es la opción del lenguaje de programación que se usa. No necesariamente serequiere de un lenguaje de programación orientada a objeto, sin embargo, si serecomienda el uso de un lenguaje de programación orientada a objeto, desde laconcepción inicial hasta la construcción. La base para la implementación es el modelo dediseñ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 deresultados de la prueba. El modelo de requerimientos de nuevo representa unaherramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos secomuniquen correctamente en dicho caso de uso. De manera simular se verifica lainterface de usuario, descrita en el modelo de requerimientos, con todo lo anterior, elmodelo 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 deconstruirlo, ya que un modelo omite los detalles no esenciales, es más sencillomanejarlos, que manejar la entidad original.

Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetosmodelo dinámico y modelo funcional.

7/16/2019 04_PD_DS_DOO.pdf





El modelo de objetos. Es el modelo más importante, ya que en él se identifican las clasesdentro del sistema junto con sus relaciones, así como sus atributos y operaciones, lo querepresenta la estructura estática del sistema. El modelo de objetos se representamediante un diagrama de clases.

El modelo dinámico. Representa los aspectos temporales de comportamiento "de controldel 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 undiagrama de flujo.

Cada modelo describe un aspecto del sistema pero contiene referencias a los demásmodelos. 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. Dichainformació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 deprogramació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 seencuentran 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 quefinalmente representa la solución del problema.

7/16/2019 04_PD_DS_DOO.pdf




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 probablesconsultas.

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érminosdel dominio del problema. Además se especifican los atributos y operaciones quedistinguen a cada una de las clases y las relaciones con las que podemos conocer suresponsabilidad en el sistema.

Figura 3.15. Nombre Clase

Dentro del diagrama de clases, una clase se representa mediante un rectángulo dondepueden existir tres separaciones, en la primer parte se coloca el Nombre de la clase, en lasegunda 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óndel 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 conellos para especificar el propósito del sistema.

7/16/2019 04_PD_DS_DOO.pdf




Figura 3.16. Escenario

Diagramas de estados: Relaciona sucesos y estados. Un diagrama de estados serepresenta mediante estados, transiciones, condiciones y acciones.

Estados: Los estados representan las respuestas de los objetos a varios sucesos endeterminado tiempo dentro del sistema. Dicha respuesta puede cambiar el estado delobjeto. Se representan mediante cuadros redondeados que contienen un nombre.

Transiciones: Se representan mediante flechas que salen del estado receptor hasta él yel nombre que se coloca en la flecha es el nombre del suceso que dio lugar a dichatransición, cada transición que sale de un estado corresponde a un suceso distinto, lo cualindica 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 deun estado a otro, si dicha condición no se cumple inclusive podría pasar a otro estadomediante otra transición o quedarse en el estado receptor hasta que la condición secumpla.

Acción: Es una operación que va asociada a un suceso y se representa mediante unabarra “/” 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 modelofuncional 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. Losdiagramas de flujo de datos son grafos que muestran el flujo de valores de datos a travésde procesos los cuales modifican dichos valores para transformarlos en otros. Losdiagramas de flujo están compuestos de:ProcesosFlujos de datos

Actores Almacenes

7/16/2019 04_PD_DS_DOO.pdf




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. Serepresenta en el diagrama por medio de una flecha, la cual puede llevar el nombre o eltipo de dato. Además de trasladar los datos a otros procesos, los flujos de datos puedenusarse para copiar un valor, realizar la composición de un agregado y así como suinverso.

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

La presente actividad tiene como propósito que reflexiones acerca de las metodologíasvistas 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 aObjetos.

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 losantecesores de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor

7/16/2019 04_PD_DS_DOO.pdf




del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemasconstruidos 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 conobjetos, 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íade la industria de objetos. El UML es un sucesor de los lenguajes de modelado de objetosderivado de las tres metodologías; (Booch, OMT y OOSE). Al conjuntar los métodos deBooch, OMT y OOSE resulta un lenguaje de modelado potente para los usuarios de éstosy otros métodos.

El UML da la idea que lo que se está haciendo, se realiza con métodos existentes. Losobjetivos que se fijaron al desarrollar el UML fueron los siguientes:

Proporcionar a los usuarios un Lenguaje de Modelado Visual de tal forma que seaposible intercambiar información de los modelos.

Proporcionar mecanismos de extensibilidad y especialización para ampliar losconceptos 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 elconsenso de los conceptos de modelado básico y permite desviaciones, las cuales se

7/16/2019 04_PD_DS_DOO.pdf




expresan en términos de mecanismos de extensión. Es un conjunto preciso que consisteen la definición de la semántica y notación del UML, definiendo también cómo se manejael Lenguaje de Especificación de Objetos.

Partiendo del hecho que el ser humano requiere de modelos para manejar sistemascomplejos, 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 desarrollode 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 granproyecto.

El UML es un Lenguaje de Modelado Visual riguroso, y ya convertido en un estándar, esla 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 delUML.

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 comoterminació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 2dimensiones.Cadenas. Representan conceptos, pueden existir como un elemento dentro de un símboloo dentro de un compartimiento de un símbolo, como elementos de una lista, comoetiquetas 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, opor 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 siguientessecciones:

El nombre de la notación a describir SemánticaNotaciónMapeoOpciones de presentación

7/16/2019 04_PD_DS_DOO.pdf




Cada punto cuenta con su propia descripción:

Nombre de la notación: Especifica el nombre de la notaciónSemá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 laidentificación de la semántica del grafo especificado.Mapeo: Indica cómo la notación puede ser representada como información semántica. Esdecir qué tipo de diagrama se utiliza, con cuáles rutas se maneja y cómo trabaja unaestructura conectada con otra estructura dentro de un mismo diagrama. Dando así elsentido 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. Envarios elementos esta sección no se presenta debido a que no tiene opciones depresentación.

3.4.2. OCL (Lenguaje de Especificaciones de Objetos)

El Lenguaje de Especificación de Objetos (Object Constraint Language, OCL), es unlenguaje formal para expresar restricciones libres de efectos colaterales. Los usuarios delLenguaje Unificado para Modelado (UML) y de otros lenguajes, pueden usar el OCL paraespecificar restricciones y otras expresiones incluidas en sus modelos. El OCL tienecaracterísticas de un lenguaje de expresión, de un lenguaje de modelado y de un lenguajeformal.

El OCL es un lenguaje de expresión puro. Por lo tanto, garantiza que una expresión OCLno tendrá efectos colaterales; no puede cambiar nada en el modelo. Esto significa que elestado del sistema no cambiará nunca como consecuencia de una expresión OCL, auncuando 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 deprograma o flujo de control en OCL. No es posible invocar procesos o activar operacionesque 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.

7/16/2019 04_PD_DS_DOO.pdf




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 significadoformalmente definido, la especificación del OCL es parte del UML. El OCL no pretendereemplazar 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 declases.

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ónreglas bien formuladas, como constantes estáticas sobre la meta-clase en lasintaxis abstracta. En varios lugares también es usado para definir operaciones „adicionales‟, que son tomadas en cuenta en la formación dereglas.

Las expresiones OCL pueden ser parte de pre-condiciones o post-condiciones, que sonRestricciones 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 conceptosbá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 lascaracterísticas de cada una de las metodologías OO y la fecha en que fueronimplementadas.

7/16/2019 04_PD_DS_DOO.pdf




3. Guarda la Actividad con el nombre ADOO_U3_A2_XXYZ donde XX es apellido(s) .yYY es tu nombre(s).


Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en estaunidad 3 del curso, es necesario que resuelvas la autoevaluación. Recuerda que es muyimportante leer cuidadosamente los planteamientos indicados y elegir la opción adecuadapara 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 cuyopropó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 losmodelos 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) yYY tu nombre(s).


* Recuerda que de ser necesario y en base a los comentarios hechos por parte de tuFacilitador(a), podrás enviar una segunda versión de tu actividad.

7/16/2019 04_PD_DS_DOO.pdf




Autorreflexiones

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 llamadoDOO_U3_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta

Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 3 del curso. A lo largo de ésta se recordaron las metodologías dediseñ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 origende la metodología UML, la cual fue a través del OCL.

Es aconsejable que revises nuevamente la unidad en caso de que los temas que seacaban de mencionar no te sean familiares, o no los recuerdes, de no ser este tu caso, yaestás preparado(a) para seguir con la unidad 4, en donde continuarás con El diseñoorientado a objetos con UML, a través de la representación de objetos y clases condiagramas 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 prototipofinal 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 deun 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




7/16/2019 04_PD_DS_DOO.pdf




Fuentes de consulta

Booch-Grady (2009) Análisis y Diseño Orientado a Objetos con aplicaciones.México: Pearson Educación.

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.

7/16/2019 04_PD_DS_DOO.pdf




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 objetosderivado de las tres metodologías (Booch, OMT y OOSE).

El UML es un lenguaje de modelado que integra a la comunidad orientada a objetos losconceptos de modelado básico y permite desviaciones, las cuales se expresan entérminos de mecanismos de extensión. Es un conjunto preciso que consiste en ladefinición de la semántica y notación del UML, definiendo también cómo se maneja elLenguaje de Especificación de Objetos.

Propósito

Con el uso constante de UML se podrá lograr una mejor comprensión entre los negocios ylos 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 lasespecificaciones de clases y objetos, evitando el costo de una mala planeación en elcomienzo.


Aplicar los tipos de diagramas para estructurar un sistema orientado a objetos mediante elmétodo de modelado UML.

7/16/2019 04_PD_DS_DOO.pdf




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 logeneral cuando se diseña una clase no es necesario mostrar todos los atributos ni todassus 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 unaclase 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: Enel 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 operacionessuprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En lasiguiente figura se ve cómo una misma clase puede representarse a distinto nivel dedetalle, según interese, y según la fase en la que se esté.

7/16/2019 04_PD_DS_DOO.pdf




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. Puederepresentarse un objeto sin un nombre específico, entonces sólo aparece el nombre de laclase.

7/16/2019 04_PD_DS_DOO.pdf




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 yobjetos 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 loscomentarios de tus compañeros.

1. Recupera lo sustancial de las lecturas del tema 4.1. Representación de objetos yclases con UML.

2. Identifica la forma más óptima para representar diferentes objetos dados por tuFacilitador(a).

3. Ingresa al foro y genera una nueva entrada.

7/16/2019 04_PD_DS_DOO.pdf




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, deforma que un diagrama es una proyección del propio sistema

El diseño de modelado UML proporciona un amplio conjunto de diagramas quenormalmente se usan en pequeños subconjuntos para poder representar las vistasprincipales 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 unadescripció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 lasclases.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íacrear un diagrama de gráfico de estado.

La siguiente figura muestra cómo se relacionan:

7/16/2019 04_PD_DS_DOO.pdf




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 delsistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a suinteracción externa.

El caso de uso es la descripción de las secuencias de acciones recíprocas entre dos omás objetos que se producen entre un actor y el sistema, cuando el actor usa el sistemapara llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, yse representa en el Diagrama de casos de uso mediante una elipse con el nombre delcaso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica queel 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.

7/16/2019 04_PD_DS_DOO.pdf




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 sepuede hacer usando los objetos y sus interacciones para derivar comportamiento delobjeto, atributos y relaciones.

Los actores dentro del modelado UML son aquellos que interactúan con el sistema adesarrollar. Las precondiciones son los hechos que se han de cumplir para que el flujo deevento 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 quehace el sistema en los casos menos frecuentes e inesperados. Por último, lasposcondiciones son los hechos que se ha de cumplir si el flujo de eventos normal se haejecutado correctamente.

El diagrama de caso de uso contiene el actor y símbolos de caso de uso, y además laslí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 amantener el sistema en ejecución o proporcionan ayuda, como las personas que operanel 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; elevento, que activa un caso de uso; y el caso de uso, que desempeña las accionesactivadas por el evento.

7/16/2019 04_PD_DS_DOO.pdf




Los casos de uso documentan un solo evento. Un caso de uso se nombra con un verbo yun 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 queel 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 fasesdel 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.

7/16/2019 04_PD_DS_DOO.pdf




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 unestudiante incluye verificar la identidad de éste.

El caso de uso Comprar libro de texto extiende el caso de uso Matricularse en la clase ypodrí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 unacaracterí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 uninterés sutil en permitir a los estudiantes cambiar su propia información personal. El hecho

7/16/2019 04_PD_DS_DOO.pdf




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 apagar 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 deusuario y contraseña antes de acceder al sistema. Ver información del estudiante permitea los estudiantes visualizar su información personal, así como también los cursos ycalificaciones.

Los diagramas de caso de uso son un buen punto de partida, pero se necesita unadescripción más completa de ellos para su documentación.

Figura 4.5. Cuatro tipos de relaciones (Kendall & Kendall, 2005: 667)

7/16/2019 04_PD_DS_DOO.pdf




4.2.2. Escenarios del caso de uso

Cada caso de uso tiene una descripción como escenario del caso de uso, el cualrepresenta 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, seavisa al actor de ello permitiéndole que los corrija.

7/16/2019 04_PD_DS_DOO.pdf




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 deactividades dentro de un sistema. Los diagramas de actividades cubren la parte dinámicade un sistema y se utilizan para modelar el funcionamiento de un sistema resaltando elflujo 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 enel estado del sistema o la devolución de un valor. Las acciones incluyen llamadas a otrasoperaciones, 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:

7/16/2019 04_PD_DS_DOO.pdf




Estados de actividad. La representación de este estado está basada en unrectángulo con las puntas redondeadas, donde el interior se representa unaactividad. El estado de actividad puede descomponerse en más sub-actividades

representadas a través de otros diagramas de actividades, estos estados puedenser interrumpidos y pueden tardar cierto tiempo en concluir. Adicional se puedenencontrar elementos como: acciones de entrada y acciones de salida, tal como semuestra en el ejemplo siguiente.

7/16/2019 04_PD_DS_DOO.pdf




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 serepresenta una acción.

Transiciones. Las transiciones muestran el paso de un estado a otro, bien seaestado de actividad o de acción. Esta transición se produce como resultado de lafinalización del estado del que parte el arco dirigido que marca la transición. Comotodo 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, yconstan de un conjunto de objetos y sus relaciones, incluyendo los mensajes que sepueden enviar unos objetos a otros. Cubren la vista dinámica del sistema. Los diagramasde secuencia enfatizan el ordenamiento temporal de los mensajes, mientras que losdiagramas de colaboración muestran la organización estructural de los objetos que envíany reciben mensajes. Los diagramas de secuencia se pueden convertir en diagramas decolaboración sin pérdida de información, lo mismo ocurre en sentido opuesto.

7/16/2019 04_PD_DS_DOO.pdf




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únla 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 verticalrepresenta el tiempo, y en el eje horizontal se colocan los objetos y actores participantesen la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y losmensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye dearriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripcionesde acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones oactivaciones a las que se refieren.

4.2.5. Diagrama de clase

Los diagramas de clase son utilizados para mostrar las relaciones entre las clases queinvolucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y decontenido.

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 unainstancia de una clase. A través de ella podemos modelar el entorno en estudio: unaCasa, un Auto, una Cuenta Corriente, etc.

En UML una clase es representada por un rectángulo que posee tres divisiones:

7/16/2019 04_PD_DS_DOO.pdf




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 comointeractú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

7/16/2019 04_PD_DS_DOO.pdf




Atributos y Métodos:

Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen elgrado 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, esdecir, es accesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólosus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, perosi 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 suentorno, é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ólootros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, perosí podrá ser accesado por métodos de la clase además de métodos de las subclases quese deriven (ver herencia).

Actividad 2. Aplicación de diagramas

Esta actividad tiene como finalidad aplicar cada uno de los conceptos básicos de losdiagramas: 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 tiposde diagramas de casos de uso de actividades secuenciales y clase, incluye su definicióny en qué utilizarías cada uno de ellos de acuerdo al concepto entendido.

7/16/2019 04_PD_DS_DOO.pdf




2. Guarda la Actividad con el nombre DOO_U4_A2_XXYZ. Sustituye las XX por las dosprimeras 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, opuede ser un objeto a lo largo de su vida. Se indican qué eventos hacen que se pase deun 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 sontransiciones 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 estadodestino.

La caja de un estado puede tener uno o dos niveles: en el primer nivel aparece el nombredel estado, el segundo nivel es opcional, y en él pueden aparecer acciones de entrada, desalida 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, cadavez 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 saledel estado por una transición de salida la acción de salida se ejecuta. Una acción internaes una acción que se ejecuta cuando se recibe un determinado evento en ese estado,

7/16/2019 04_PD_DS_DOO.pdf




pero que no causa una transición a otro estado. Se indica en la formanombre_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 laque hay un estado inicial de creación y un estado final de destrucción (finalización delcaso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólidoy el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estadosinicial 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 delosdiagramas 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 lasdos 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.

7/16/2019 04_PD_DS_DOO.pdf





Autoevaluación

Para reforzar los conocimientos relacionados con los temas que se abordaron en estaunidad del curso, es necesario que resuelvas la actividad integradora. Recuerda que esmuy importante leer cuidadosamente los planteamientos indicados y elegir la opciónadecuada para cada uno.

Evidencia de aprendizaje. Diagramas UML

Como parte de la evaluación de esta unidad, realiza la siguiente actividad cuyo propósitoes conceptualizar el proceso de diagramación.

Instrucciones:

1. En un archivo de texto o Microsoft Visio diseña un ejercicio para cada uno de losdiagramas 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 lasdos 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

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

7/16/2019 04_PD_DS_DOO.pdf




DOO_U4_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad

Has concluido la unidad 4 del curso. A lo largo de ésta se vieron conceptos de diseñoorientado a objetos con UML, cómo se representan los objetos y las clases, además decó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.

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 éste tu caso, yahabrá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ágina73.

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 Orientadoa 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






7/16/2019 04_PD_DS_DOO.pdf



Kendall, J. & Kendall, J. (1990) Análisis y Diseño de sistemas. México: PrenticeHall 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.pdf

Documents

Transcript of 04_PD_DS_DOO.pdf