Desarrollo De Softwarw

INSTITUTO TECNOLOGICO SUPERIOR DE COATZACOALCOS

DESARROLLO DE PROYECTO DE SOFTWARE

UNIDAD 2

DISEÑO ORIENTADO A OBJETOS.

ALUMNA:

HERNANDEZ SUNFELD JENNY ASENETH

GRADO-GRUPO:

8 B

PROFESORA:

ZOFIA BENITEZ ALONSO

COATZACOALCOS, VER. 19 DE MARZO DEL 2013.

INTRODUCCIÓN

El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial. Esto implica que son necesarias técnicas y tecnología eficientes de Ingeniería de Software para resolver los múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas software de gran tamaño.

La Ingeniería de Software implica seguir en cualquier proyecto de software una metodología de desarrollo y la utilización de distintas técnicas y herramientas. Los diferentes procedimientos a seguir en cualquier proyecto de Ingeniería de software son:

Definición de requerimientos, Análisis, Diseño, Verificación y Validación (Pruebas de Calidad del Software), Pruebas y Mantenimiento.

El presente documento intenta dar a conocer y describir los conceptos y aspectos fundamentales del diseño orientado a objetos dentro del desarrollo de un producto software, así como las técnicas, metodologías y herramientas actuales de dicho paradigma en la Ingeniería de software.

Así pues, definimos Diseño de Software como la acción de construir soluciones que satisfagan los requerimientos del cliente. Existen varias etapas en el proceso de diseño de software, a saber son:

• Entendimiento del problema

• Identificar una o mas soluciones

• Describir abstracciones de la solución

• Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Cualquier diseño debe ser modelado como una gráfica dirigida hecha de entidades con atributos los cuales participan en relaciones. El sistema debe estar descrito a distintos niveles de abstracción y el diseño ocurre en etapas que se traslapan.

La primera idea que se tiene al construir una solución de un determinado problema es un modelo mental que constituye el primer intento de diseño llamado comúnmente informal. Este diseño a medida que se va describiendo en papel utilizando técnicas y procedimientos esquemáticos y metódicos va adquiriendo forma hasta constituirse en un diseño formal equivalente.

DISEÑO ORIENTADO A OBJETOS UNIDAD II.

2.1 Diseño del sistema en base a procesos.

La primera actividad en el proceso de desarrollo de sistemas involucra al equipo de trabajo en el conocimiento del problema para establecer los requerimientos en términos confiables y especificaciones formales y concretas.

El proceso de análisis de requerimientos pretende acelerar las curvas de aprendizaje mediante subprocesos que permitan extraer el conocimiento clave de los usuarios hacia estructuras incrementales de conocimiento, de tal forma que los miembros del equipo de desarrollo, puedan llegar más rápidamente a la parte acelerada de la curva de aprendizaje.

Sin embargo, ésta adquisición de conocimientos no será sólo capacitación, sino también, debe aprovecharse para establecer los requerimientos básicos del sistema.

El Modelo de Requerimientos se constituye a su vez de tres modelos:

• Modelo de casos

• Modelo de Interfaz

• Modelo de Dominio del Problema

Cada uno contempla parte del conocimiento del usuario orientado a la especificación de las funciones básicas del sistema.

El Modelo de Casos extrae el conocimiento funcional fundamental del problema de una forma estructurada y progresiva, siendo la base para establecer la estructura del sistema. Este modelo orienta todos las demás procesos del método.

El modelo de Interfaz establece el vínculo visual entre el desarrollador y el usuario para concretar aspectos de la interacción que el sistema pudiese tener con su entorno externo, permitiendo la retroalimentación temprana de aspectos fundamentales para el conocimiento de la aplicación.

En el Modelo del Dominio del Problema se establecerán los principales objetos que constituirán al sistema y las relaciones que tienen entre sí.

2.1.1 Actividades y casos de uso.

Modelado de casos de uso

Un caso real de uso describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global.

Por ejemplo, si interviene una interfaz gráfica para el usuario, el caso de uso real incluirá diagramas de las ventanas en cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz.

Los diagramas de casos de uso pueden llegar a ser bastante grandes esto no es malo con los modelos grandes, siempre y cuando se agregue valor al esfuerzo global. El hecho es que se puede llegar a crear un modelo de gran tamaño que describe los requisitos para su sistema, y puede incluir un modelo de casos de uso general que se han creado durante meses o años de trabajo evolutivo. No deben ser creados todos por adelantado antes de empezar a programar.

Figura 2.1: Boceto inicial de un diagrama de casos de uso.

Ahora veamos lo que el simple diagrama de la figura. 2.1 podría evolucionar.

El diagrama de casos de uso en la figura 2.2. Abajo proporciona un ejemplo de un diagrama de casos de uso UML:

Figura 2.2: Un simple diagrama de casos de uso para una universidad.

En el ejemplo representado en la figura 2.2. Los estudiantes se matriculan en cursos con la ayuda del encargado de admisión. Los profesores ingresan las notas obtenidas por los estudiantes de las actividades asignadas y el encargado administrador autoriza la publicación de calificaciones a los estudiantes.

La asociación entre el estudiante e inscrito en seminario señala que el caso de uso es invocado, inicialmente por un estudiante y no por un encargado de admisión (el encargado de admisión es también un actor y está involucrado en este caso de uso). Entendiendo que las asociaciones no representan flujo de información es importante, simplemente indican que un actor es de alguna manera involucrado en un caso de uso. La información fluye de ida y vuelta entre el actor y el caso de uso, por ejemplo, los estudiantes deben indicar a qué seminarios quieren inscribirse en el sistema y tendría que indicar a los estudiantes si han sido inscritos.

Figura 2.3: Diagrama de casos de uso más complejo de la misma universidad

Los Diagramas de casos de uso dan una visión general muy buena de los requisitos. A menudo se dibuje un diagrama de casos de uso mientras se están identificando los actores del caso de uso y las asociaciones entre ellos.

Sugieren que los diagramas de casos de uso deben ser desarrollados desde el punto de vista del usuario y no del desarrollador. Su objetivo es modelar los requisitos de comportamiento para el sistema y cómo los usuarios trabajan con el sistema para satisfacer sus necesidades, no lo que los desarrolladores creen que deben construir.

Identificación de los actores

Un actor representa a cualquier cosa o alguien que interactúa con el sistema. Esto puede incluir a las personas (no sólo el usuario final), los sistemas externos, y otras organizaciones. Los actores son siempre externos al sistema que está siendo modelado, ellos nunca son parte del sistema. Para ayudar a encontrar a los actores en el sistema, debe hacerse las siguientes preguntas:

¿Quién es el principal cliente de su sistema?

¿Quién obtiene la información de este sistema?

¿Quién proporciona información al sistema?

¿Quién instala el sistema?

¿Quién opera el sistema?

¿Quién apaga el sistema?

¿Qué otros sistemas interactúan con este sistema?

¿Hay algo que sucederá de forma automática a una hora predeterminada?

¿Quién suministro, utilización, o eliminar la información del sistema?

¿De dónde viene el sistema de obtener información?

Identificación de casos de uso

Una forma en preguntando a sus interesados las siguientes preguntas desde el punto de vista de los actores:

¿Cuáles son los usuarios de este rol tratando de realizar?

¿Qué deben ser capaces los usuarios de hacer?

¿Cuáles son las principales tareas de los usuarios en este papel?

¿Qué información necesitan examinar, crear o cambiar los usuarios de este perfil?

¿Qué información necesitan los usuarios de este perfil del sistema?

¿Qué hacen los usuarios en este perfil que necesitan informar al sistema.

Los sistemas y sus fronteras.

Un caso de uso describe la interacción con un "sistema". Las fronteras ordinarias del sistema son:

− La frontera hardware/software de un dispositivo o sistema de cómputo

− El departamento de una organización

− la organización entera

Figura 2.4 fronteras de un sistema

Es importante

...