Anlisis y diseo orientado a objetos

Programa desarrollado

Ingeniera en Desarrollo de Software Cuatrimestre 04

Programa de la asignatura: Anlisis y diseo orientado a objetos

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos

Clave: 160920413 / 150920413

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado
ndice

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos ......................... 3 Presentacin de la unidad........................................................................................................... 3 Propsito ........................................................................................................................................ 4 Competencia especfica .............................................................................................................. 4 2.1. Levantamiento de requerimientos ...................................................................................... 5 2.1.1. Introduccin a los requerimientos ................................................................................... 5 2.1.2. Actividades para el levantamiento de requerimientos ................................................. 6 Actividad 1. Anlisis y diseo en un programa orientado a Objetos .................................... 7 2.2. Documentacin para levantamientos y especificaciones ............................................... 7 2.2.1. Documentacin .................................................................................................................. 8 2.2.2. Especificaciones ................................................................................................................ 9 2.3. Estndares de especificacin ............................................................................................. 9 2.3.1. Fases de la estandarizacin .......................................................................................... 10 2.3.2. Anlisis de restricciones ................................................................................................. 11 Actividad 2. Requerimientos para disear un programa ...................................................... 11 2.4. Modelos del desarrollo del software ................................................................................ 12 2.4.1. giles ................................................................................................................................. 13 2.4.2. Predictivos ........................................................................................................................ 14 Actividad 3. Listado de caractersticas de los modelos giles y predictivos ..................... 15 Autoevaluacin ........................................................................................................................... 16 Evidencia de aprendizaje. Requerimientos para disear un programa con O O ............. 16 Cierre de la unidad ..................................................................................................................... 17 Fuentes de consulta ................................................................................................................... 17

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado

Unidad 2. Requerimientos para el anlisis del diseo orientado a objetos Presentacin de la unidad
El trabajo de ir detallando la definicin de un problema en forma de requisitos se realiza de manera repetitiva, progresiva, incremental. Por un lado, supone la planificacin, realizacin y evaluacin de las entrevistas con los clientes y usuarios finales del sistema, que son los portadores de la informacin necesaria para conocer el problema y definir el proyecto. Por otro lado, supone la identificacin y descomposicin reiterada (hasta el nivel de detalle que en cada caso sea necesario) de los problemas y necesidades expresados por el cliente y los usuarios, para as ir redactando un conjunto de requisitos formales. Principalmente, se utiliza la siguiente tcnica: Entrevista. Es una conversacin dirigida por objetivos entre un entrevistador, miembro del equipo de desarrollo, y un entrevistado, que suele ser el cliente o un usuario final. Es importante crear desde el principio un clima de cordialidad y confianza, atendiendo siempre a las opiniones del entrevistado. l es nuestra fuente de informacin principal y de la relacin que establezcamos depende la facilidad o dificultad para conocer sus necesidades. Es bueno tener en cuenta que a veces surgen dificultades y mal entendidos; la resistencia al cambio, usuarios que ven el nuevo sistema como una amenaza para su futuro trabajo, expertos reticentes a compartir conocimientos. Durante la realizacin de una entrevista lo habitual es la toma de notas, para redactar ms tarde el informe de evaluacin de la misma. Para la grabacin en audio o en video es preceptivo el permiso expreso del entrevistado, siendo conveniente tener en cuenta si esto va a interferir en la entrevista, hacindole sentir incmodo. Pese a su costo, se va generalizando el uso de videoconferencias para la realizacin de entrevistas remotas, con la consiguiente comodidad para ambas partes. Toda entrevista requiere de una preparacin previa: establecer los objetivos, seleccionar al entrevistado, concertar la cita, hacer lectura de antecedentes, proporcionar y pedir documentacin, elegir el tipo de preguntas para finalmente utilizar la informacin recabada para lograr los fines. Segn el tipo de preguntas, existen diferentes clases de entrevista: Inductiva: se comienza con preguntas cerradas, para ir pasando, a lo largo de la entrevista, hacia preguntas abiertas.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado
Deductiva: al principio se hacen preguntas abiertas y se va acotando con preguntas cada vez ms 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 gustara recibir de su sistema?

Para poder formular preguntas cerradas es necesario anticipar las posibles alternativas de respuesta. Algunos ejemplos de preguntas cerradas: Firmamos el contrato? Le gusta nuestro producto?

Propsito
La especificacin de requisitos es la primera fase de todo ciclo de vida o metodologa de desarrollo de un proyecto informtico. Dos son sus objetivos principales: Identificar las necesidades del cliente, es decir, conocer y definir el problema. Realizar un estudio de viabilidad econmico, tcnico y legal, a partir del cual se pueda decidir sobre la continuacin del proyecto, teniendo en cuenta las alternativas de construccin del mismo que se nos planteen.

Estos dos objetivos principales se concretan en una serie de acciones a realizar, unas tcnicas a aplicar y unos productos a obtener. Resulta obvio (en cualquier contexto, no solo en el terreno informtico) que un primer paso necesario para solucionar un problema es tenerlo definido correcta y detalladamente. Esto implica dos cosas: Es fundamental centrar la necesidad del cliente para poder definir el problema que se va a resolver, tratando de dejar claro lo que queda dentro y fuera del alcance del mismo. En este momento se est hablando de la definicin, desde el punto de vista puramente tcnico, del proyecto. Un aspecto importante a tener en cuenta es la identificacin de los tipos de usuarios potenciales que tendr el sistema.

Competencia especfica
Distinguir los requerimientos del sistema orientado a objetos en su etapa de anlisis para definir su diseo mediante tcnicas y estndares de especificacin.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado

2.1. Levantamiento de requerimientos

A partir de las entrevistas, reuniones, etc., se ha definido el problema; es decir, se ha obtenido la Especificacin de Requisitos. En ella se describe lo que el sistema nuevo debe realizar. Y se ha averiguado, mediante un estudio de viabilidad, si el sistema se puede desarrollar o no.

2.1.1. Introduccin a los requerimientos

Ahora, se va a realizar el siguiente paso del Ciclo de Vida: Anlisis del sistema. Consiste en analizar los requisitos para centrarse en qu debe hacer el sistema. Con el Anlisis del sistema se pretende: Organizar la informacin; es decir, reflejar la informacin del problema en un formato grfico, ms fcil de manejar. Este formato hace que los requisitos sean entendibles para el diseador y, a la vez, facilita la comunicacin con el usuario. Depurar todo aquello que no interesa y concentrarse en lo que debe hacer el sistema. Sacar a la superficie y resolver posibles conflictos. Dividir el problema en sub-problemas ms fciles de resolver.

As pues, toda aplicacin se apoya en tres pilares o consta de tres partes principales: Procesos. Son la parte funcional de la aplicacin. Reflejan las funciones o tareas que debe realizar la aplicacin, muestran cmo se transforman los datos. Datos. Son la parte esttica de la aplicacin. Se refieren a la informacin que se necesita almacenar. Eventos. Son la parte dinmica de la aplicacin. Muestran los aspectos del sistema que cambian con el tiempo. Provocan la ejecucin de la operacin adecuada en cada momento. Son los que activan la aplicacin (la ponen en marcha) y propagan esa activacin a lo largo de la aplicacin, desencadenando la ejecucin de otras operaciones. Los eventos llevan el control de la aplicacin introduciendo el dinamismo necesario para su ejecucin. Los eventos tienen mucha relacin con la interfaz de la aplicacin. Porque a travs de la interfaz se introducen los eventos.

Los procesos dicen qu hay que hacer. Los datos indican con qu hay que hacerlo. Y los eventos muestran cundo hay que hacerlo.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado

Los tres pilares son complementarios, no tiene ms importancia uno que otro, se necesitan los tres. En algunos sistemas predomina ms uno que otro, pero siempre estn presentes los tres. Para especificar cada uno de los tres pilares se utilizan Modelos. Un Modelo es una representacin abstracta de la realidad. Por tanto, como resultado del anlisis se obtendrn: Modelo de Procesos, de modelo de Datos y de modelo de Eventos Modelo de Procesos: recoge qu funciones, actividades, tareas, acciones, debe realizar la aplicacin y cmo manejar los datos. Modelo de Datos: describe la informacin que maneja la aplicacin, los datos que debe almacenar. Y muestra cmo organizarla. Modelo de Eventos: Indica en qu momento debe ejecutarse cada accin. Para construir cada modelo hay diferentes tcnicas, algunas son complementarias.

Figura 2.1. Modelos. En la fase de anlisis se pretende que los modelos (de procesos, de datos y de eventos) estn lo suficientemente detallados sin llegar a descender al diseo. El anlisis tiene por objetivo entender el problema: las necesidades del cliente, las restricciones que se deben cumplir. El diseo pretende obtener una solucin ptima que cumpla todos los requisitos. Se orienta hacia la mquina, centrndose en cmo crear un sistema software que rena todas las necesidades y cumpla todas las restricciones.

2.1.2. Actividades para el levantamiento de requerimientos

El levantamiento de requerimientos incluye tres tipos de actividad:

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado
Sacar requisitos: la tarea de comunicarse con los clientes y los usuarios para determinarse cules son sus requisitos. Esto a veces tambin se llama acopio de los requisitos. Analizar requisitos: determinndose si los requisitos indicados son confusos, incompletos, ambiguos, o contradictorios, y despus resolviendo estas ediciones. Requisitos de la grabacin: Los requisitos se pueden documentar en varias formas, tales como documentos de lenguaje natural, utilice los casos, historias del usuario, o especificaciones de proceso.

Actividad 1. Anlisis y diseo en un programa orientado a Objetos

El propsito de esta actividad es que reflexiones acerca de los requerimientos para llevar a cabo un anlisis y diseo orientado a objetos. Para ello: 1. Retoma lo revisado en el tema 2.1.Levantamiento de requerimientos. 2. Identifica todos los requerimientos que se deben cumplir antes de un anlisis y diseo orientado a objetos. 3. Ingresa al foro, genera una nueva entrada y participa.

2.2. Documentacin para levantamientos y especificaciones

La documentacin rene todas las actividades dedicadas bsicamente a planificar el proceso de ADOO y mantener los documentos necesarios para los desarrolladores y los usuarios. El esquema formal que debe tener una especificacin de requisitos es el siguiente: 1. ndice 2. Descripcin del mbito y alcance del proyecto 3. Lista de usuarios participantes 4. Descripcin del sistema actual 5. Catlogo (priorizado) de requisitos del sistema a. Funcionales b. No funcionales i. Restricciones ii. De funcionamiento * Del sistema * Requisitos software * Requisitos hardware

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado
iii. Manejo de excepciones 6. Anlisis de alternativas a. Descripcin de la alternativa 1 b. Descripcin de la alternativa 2 c. Descripcin detallada de la alternativa seleccionada i. Modelo lgico de procesos ii. Anlisis costo-beneficio iii. Diferencias significativas con las dems alternativas 7. Apndices (si es necesario)

2.2.1. Documentacin
La documentacin de los requerimientos, es una de la parte importante durante en el anlisis. En la prctica es comn describir los requerimientos en un documento, llamado especificacin de requerimientos del software, su principal objetivo es de comunicar de forma efectiva los requerimientos, objetivos del dominio. En primera instancia la documentacin contiene la informacin que aporta el cliente que encarga la aplicacin, contiene todos los registros de las reuniones de trabajo del grupo de anlisis. Documentos bsicos de anlisis orientado a objetos: Documentos de anlisis Especificacin de requisitos o requerimientos Diagramas de casos de uso Escenarios y sub-escenarios Prototipos y su evaluacin

Todos los documentos deben estar identificados y codificados. Identificacin Es necesario identificar todos los elementos del proceso de desarrollo de software de una forma nica. El ttulo debe reflejar de la mejor forma posible sus fines y su funcionalidad. Descripcin Autores Versin. Notacin decimal. Revisin. Autores Fecha Cdigo de cada documento o diagrama

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado

Documentos de anlisis Contiene la documentacin que aporta el cliente que encarga la aplicacin. Tambin contiene las actas de las reuniones de trabajo del grupo de anlisis, es necesario un secretario que tome acta y es necesario aprobar el acta de cada reunin por todos los miembros.

2.2.2. Especificaciones
Expresa las caractersticas esenciales de un objeto, las cuales distinguen al objeto uno de otro. A parte de distinguir los objetos tambin provee lmites conceptuales, permitiendo que se disponga de las caractersticas de un objeto que se necesite. El objetivo principal de las especificaciones, es en entregar una especificacin de requisitos que ayuden a determinar de forma completa y correcta el diseo orientado a objetos.

2.3. Estndares de especificacin

Las especificaciones del software determina el proceso de comprensin y definicin sobre los servicios que se requieren del sistema y de identificacin de las restricciones de funcionamiento y desarrollo del mismo. La ingeniera de requerimientos es un proceso crtico en el proceso del software, los errores en esta etapa originan problemas posteriores en el diseo e implementacin del sistema. En la siguiente figura se muestra el proceso de ingeniera de requerimientos. ste conduce a la produccin de un documento de requerimientos, que es la especificacin del sistema. Normalmente en este documento los requerimientos se presentan en dos niveles de detalle. Los usuarios finales y los clientes necesitan una declaracin de alto nivel de los requerimientos, mientras que los desarrolladores del sistema necesitan una especificacin ms detallada de ste.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

Anlisis y diseo orientado a objetos

Programa desarrollado

Figura 2.2. Estndares de especificacin.

2.3.1. Fases de la estandarizacin

Existen cuatro fases principales en el proceso de estndares de ingeniera de requerimientos: 1. Estudio de viabilidad. Se estima si las necesidades del usuario se pueden satisfacer con las tecnologas actuales de software y hardware. El estudio analiza si el sistema propuesto ser rentable desde un punto de vista de negocios y si se puede desarrollar dentro de las restricciones de presupuesto existentes. Este estudio debe ser relativamente econmico de elaborar. EI resultado debe informar si se va a continuar con un anlisis ms detallado. 2. Obtencin y anlisis de requerimientos. Es el proceso de obtener los requerimientos del sistema por medio de la observacin de los sistemas existentes, discusiones con los usuarios potenciales y proveedores, el anlisis de tareas, etctera. Esto puede implicar el desarrollo de uno o ms modelos y prototipos del sistema que ayudan al analista a comprender el sistema a especificar. 3. Especificacin de requerimientos. Es la actividad de traducir la informacin recopilada durante la actividad de anlisis en un documento que define un conjunto de requerimientos. En este documento se pueden incluir dos tipos de requerimientos: los requerimientos del usuario, que son declaraciones abstractas de los requerimientos del cliente y del usuario final del sistema, y los requerimientos del sistema, que son una descripcin ms detallada de la funcionalidad a proporcionar. 4. Validacin de requerimientos. Esta actividad comprueba la veracidad, consistencia y completitud de los requerimientos. Durante este proceso, inevitablemente se descubren errores en el documento de requerimientos. Se debe modificar entonces para corregir estos problemas.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

10

Anlisis y diseo orientado a objetos

Programa desarrollado
Por supuesto, las actividades en el proceso de requerimientos no se llevan a cabo de forma estrictamente secuencial. El anlisis de requerimientos contina durante la definicin y especificacin, y a lo largo del proceso surgen nuevos requerimientos. Por lo tanto, las actividades de anlisis, definicin y especificacin se entrelazan. En los mtodos giles como la programacin extrema, los requerimientos se desarrollan de forma incremental conforme a las prioridades del usuario, y la obtencin de requerimientos viene de los usuarios que forman parte del equipo de desarrollo.

2.3.2. Anlisis de restricciones

Las restricciones son relaciones entre entidades de un modelo de objetos, el trmino de entidad, incluye los objetos, clases, atributos, enlaces y asociaciones. Una restriccin reduce los valores que una entidad puede tomar. Restricciones entre objetos. Determina el estado en el cual los objetos se diferencian uno al otro, ejemplo: Horario de entrada de un empleado de oficina no puede ser despus de las 9:00, suponiendo que el horario de entrada al trabajo es a las 9:00. Restricciones entre atributos de un objeto: Determina los atributos especficos de un objeto, ejemplo: El objeto alumno solo debe tener como atributos, nombre completo y no apellido paterno, apellido materno y nombre. Restricciones sobre un objeto a lo largo del tiempo. Determina el estado del objeto donde especifica que nunca debe de cambiar su estado, ejemplo: El objeto alumno no puede aumentar su nmero de control.

Las restricciones simples pueden situarse en el modelo de objetos, restricciones complejas aparecern en el modelo funcional. Las restricciones no tienen por qu aparecer inicialmente en el modelo de objetos, estas irn aadindose conforme se vaya concretando en la definicin del modelo.

Actividad 2. Requerimientos para disear un programa

Con el fin de aplicar cada uno de los conceptos bsicos de los estndares de especificaciones de un anlisis, disea un programa con orientacin a objetos haciendo un documento que sirva como base para conocer los requerimientos para disear el programa de un saln de belleza. 1. Plantea una situacin hipottica o pregunta al encargado(a) de un saln de belleza acerca de qu le gustara controlar por computadora (Obtencin y anlisis de requerimientos).

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

11

Anlisis y diseo orientado a objetos

Programa desarrollado

2. Con base en la informacin obtenida, en un archivo de texto escribe los requerimientos del usuario y del sistema (Especificacin de requerimientos). 3. Apunta si es viable o no (Validacin de requerimientos). 4. Guarda tu actividad con la nomenclatura DOO_U2_A2_XXYZ. 5. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

2.4. Modelos del desarrollo del software

Las metodologas se centra en una serie de combinaciones de los modelos de proceso genricos (cascada, evolutivo, incremental, etc. Adicionalmente una metodologa debe definir con precisin los roles y actividades involucradas, junto con prcticas, guas de adaptacin. Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o diseo. La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas Tradicionales (o peyorativamente denominada Metodologas Pesadas, o Peso Pesado). Otras metodologas, denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso. Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin Estructurada, luego a mediados de los 70s aparecieron tcnicas primero para el Diseo (por ejemplo: el diagrama de Estructura) y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la implementacin lenguajes de 3ra y 4ta generacin.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

12

Anlisis y diseo orientado a objetos

Programa desarrollado
Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia), MTRICA (Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos estructurados en el mbito acadmico: Gane & Sarson, Ward & Mellor, Yourdon & De Marco e Information Engineering. Metodologas orientadas a objetos, va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a consolidarse algunos mtodos Orientados a Objeto En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto, para dar lugar al Unified Modeling Language (UML), la notacin OO ms popular en la actualidad (Booch-Grady, 1996)). Algunos mtodos OO con notaciones predecesoras de UML son: OOAD (Booch), OOSE (Jacobson), Coad&Yourdon, Shaler&Mellor y OMT (Rumbaugh). Algunas metodologas orientadas a objetos que utilizan la notacin UML son: Rational Unified Process (RUP), OPEN, MTRICA (que tambin soporta la notacin estructurada).

2.4.1. giles
Nuevas tcnicas para aplicar las prcticas esenciales de la programacin extrema y mtodos giles para desarrollar sistemas orientados a objetos se encuentre la metodologa gil. Es cuando el desarrollo de software es incremental (entregas pequeas de software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo momento) El modelado gil tambin abarca un conjunto de principios esenciales. Adems delos principios esenciales de la programacin extrema, el modelado gil agrega principios tales como "modelar con un propsito", "el software es su meta principal" y "viajar con poco equipaje", una forma de decir que poca documentacin es suficiente. Entre las metodologas giles identificadas: Extreme Programming Scrum Familia de Metodologas Crystal Feature Driven Development

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

13

Anlisis y diseo orientado a objetos

Programa desarrollado
ProcesoUnificado Rational, unaconfiguracingil Dynamic Systems Development Method Adaptive Software Development Open Source Software Development

2.4.2. Predictivos
Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema. Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas tradicionales por el especial nfasis que presenta en cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a aplicarse), realizando una configuracin adecuada, podra considerarse gil. La inspiracin usual para las metodologas han sido disciplinas como las ingenieras civil o mecnica. Tales disciplinas enfatizan que hay que planear antes de construir. Los ingenieros trabajan sobre una serie de esquemas que indican precisamente qu hay que construir y cmo deben juntarse estas cosas. Muchas decisiones de diseo, como la manera de controlar la carga sobre un puente, se toman conforme los dibujos se producen. Los dibujos se entregan entonces a un grupo diferente, a menudo una compaa diferente, para ser construidos. Se supone que el proceso de la construccin seguir los dibujos. En la prctica los constructores se encuentran con algunos problemas, pero stos son normalmente poco importantes. Como los dibujos especifican las piezas y cmo deben unirse, actan como los fundamentos de un plan de construccin detallado. Dicho plan define las tareas que necesitan hacerse y las dependencias que existen entre estas tareas. Esto permite un plan de trabajo y un presupuesto de construccin razonablemente predecibles. Tambin dice en detalle cmo deben hacer su trabajo las personas que participan en la construccin. Esto permite que la construccin requiera menos pericia intelectual, aunque se necesita a menudo mucha habilidad manual. As que lo que vemos aqu son dos actividades fundamentalmente diferentes. El diseo, que es difcil de predecir y requiere personal caro y creativo, y la construccin que es ms fcil de predecir. Una vez que tenemos el diseo, podemos planear la construccin. Una vez que tenemos el plan de construccin, podemos ocuparnos de la construccin de una manera ms predecible. En ingeniera civil la construccin es mucho ms costosa y tardada que el diseo y la planeacin.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

14

Anlisis y diseo orientado a objetos

Programa desarrollado
As el acercamiento de muchas metodologas es: queremos un plan de trabajo predecible que pueda usar gente del ms bajo nivel. Para hacerlo debemos separar el plan de la construccin. Por consiguiente necesitamos entender cmo hacer el diseo de software de modo que la construccin pueda ser sencilla una vez que el plan est hecho. Qu forma toma este plan? Para muchos, ste es el papel de notaciones de diseo como el UML. (Lenguaje de Modelado Unificado) Si podemos hacer todas las decisiones significativas usando UML, podemos armar un plan de construccin y entonces podemos dar planes a los programadores como una actividad de construccin. Pero aqu surgen preguntas cruciales. Es posible armar un plan que sea capaz de convertir el cdigo en una actividad de construccin predecible? Y en tal caso, es la construccin suficientemente grande en costo y tiempo para hacer valer la pena este enfoque? Todo esto trae a la mente ms preguntas. La primera es la cuestin de cun difcil es conseguir un diseo UML en un estado que pueda entregarse a los programadores. El problema con un diseo tipo UML es que puede parecer muy bueno en el papel, pero resultar seriamente fallido a la hora de la programacin. Los modelos que los ingenieros civiles usan estn basados en muchos aos de prctica guardados en cdigos ingenieriles. Adems los problemas importantes, como el modo en que juegan las fuerzas, son dciles al anlisis matemtico. La nica verificacin que podemos hacer con los diagramas UML es la revisin cuidadosa. Mientras esto es til trae errores al diseo que slo se descubren durante la codificacin y pruebas. Incluso los diseadores experimentados se sorprenden a menudo cuando convierten dichos diseos en software. Otro problema es el costo comparativo. Cuando se construye un puente, el costo del esfuerzo en el plan es aproximadamente un 10% del total, siendo el resto la construccin. En software la cantidad de tiempo gastada codificando es mucho, mucho menor. Se sugiere que para un proyecto grande, slo 15% del proyecto son cdigo y pruebas unitarias, una inversin casi perfecta de las proporciones de la construccin del puente. Aun cuando se consideren las pruebas parte de la construccin, el plan es todava 50% del total. Esto genera una pregunta importante sobre la naturaleza del diseo en software comparado con su papel en otras ramas de la ingeniera.

Actividad 3. Listado de caractersticas de los modelos giles y predictivos

Como parte de la evaluacin realiza la siguiente actividad cuyo propsito es distinguir entre modelos giles y predictivos.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

15

Anlisis y diseo orientado a objetos

Programa desarrollado
1. En un archivo de texto, realiza un listado comparativo de los modelos giles y predictivos, teniendo en cuenta las definiciones vistas en los temas anteriores. Ejemplo:

2. Guarda tu actividad con la nomenclatura DOO_U2_A3_XXYZ. 3. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Autoevaluacin
Para reforzar los conocimientos relacionados con los temas que se abordaron en esta segunda unidad del curso, es necesario que resuelvas la autoevaluacin. Recuerda que es muy importante leer cuidadosamente los planteamientos indicados y elegir la opcin adecuada para cada uno.

Evidencia de aprendizaje. Requerimientos para disear un programa con O O

Como parte de la evaluacin de esta unidad, debes llevar a cabo esta actividad cuyo propsito es aplicar los conceptos aprendidos en la unidad. 1. En un archivo de texto detalla un levantamiento de requerimientos que cumpla con los estndares para disear un programa con OO para el control de una papelera y menciona el modelo de software a aplicar en la misma. 2. Consulta la Escala de evaluacin. 3. Guarda la evidencia con el nombre DOO_U2_EA_XXYZ. 4. Enva el archivo a tu Facilitador(a) para recibir retroalimentacin.

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

16

Anlisis y diseo orientado a objetos

Programa desarrollado

Autorreflexiones
Adems de enviar tu Evidencia de aprendizaje, es importante que ingreses al foro Preguntas de Autorreflexin y consultes las preguntas que tu Facilitador(a) presente, a partir de ellas, debes elaborar tu Autorreflexin en un archivo de texto llamado DOO_U2_ATR_XXYZ. Posteriormente enva tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad
Has concluido la unidad 2 del curso a lo largo de esta trabajaste con la documentacin de requerimientos para el anlisis orientado a objetos, comenzando con la parte de levantamiento de requerimientos, que incluye el describir cules son los requerimientos y que actividades necesitas realizar para el levantamiento de los mismos. Tambin identificas cual es la documentacin para el levantamiento y que especificaciones debe cumplir considerando sus estndares, divididos en sus fases y anlisis de restricciones. Por ltimo en esta unidad debes distinguir que modelos del desarrollo de software se manejan y si son giles o predictivos. Es aconsejable que revises nuevamente la unidad en caso de que los temas que se acaban de mencionar no te sean familiares o no los recuerdes, de no ser este t caso, ya ests preparado(a) para seguir con la unidad 3, en donde continuars con la Metodologas de Diseo para la Generacin de Sistemas Orientados a Objetos, tales como Bosh, OOC, OMT y UML. Todo ello con el fin de terminar la ltima unidad del curso de Anlisis y diseo orientado a objetos.

Fuentes de consulta
Booch-Grady (1996) Anlisis y Diseo Orientado a Objetos con Aplicaciones. Mxico: Pearson Educacin. Cueva, J. (2005) Ingeniera del Software. Madrid: Pearson Educacin. Cueva, J. (2005) Anlisis 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 metodologa. Traduccin de Alejandro Sierra para programacionextrema.org. Recuperado el 22 de julio de 2011 de: http://www.programacionextrema.org/articulos/newMethodology.es.html

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

17

Anlisis y diseo orientado a objetos

Programa desarrollado
Garca, S. y Morales, E. (2003) Desarrollo de aplicaciones informticas. Anlisis y diseo detallado de aplicaciones informticas de gestin. Mxico: Ed. Thompson. Kendall, E. (2005) Anlisis y Diseo de sistemas. Mxico: Pearson Educacin. Letelier, P. y Penads, M. (s/f) Metodologas giles para el desarrollo de software: eXtremeProgramming (XP). Universidad Politcnica de Valencia. Recuperado el 22 de julio de 2011 de: http://www.willydev.net/descargas/masyxp.pdf WorldLingo (2011) Anlisis de requisitos. WorldLingoTranslations LLC. Recuperado el 22 de julio de 2011 de: http://www.worldlingo.com/ma/enwiki/es/Requirements_analysis

Ciencias Exactas, Ingenieras y Tecnologa | Desarrollo de Software

18