Un desarrollo de software tiene xito si se han comprendido perfectamente los requisitos del software.

Si un programa se analiza y especifica pobremente, decepcionar al usuario y desprestigiar a quien lo ha desarrollado.

El anlisis se sintetiza en 5 tareas:

Reconocimiento del Problema Evaluacion y Sntesis
Modelizacin

Especificacin

Revisin

Reconocimiento del Problema Inicialmente se debe estudiar la definicin del Sistema y el Plan del Proyecto para comprender el sistema y revisar las razones que se usaron para hacer las estimaciones en la planeacin.

Evaluacion y Sntesis El analista definir todas las funciones del software, establecer las caractersticas de la interfaz y las restricciones de diseo. Esto servir finalmente para sintetizar una solucin global. El analista debe centrarse en el qu ( qu se hace, qu se tiene, qu se puede hacer ) y no en el cmo.

Modelizacin
Durante la evaluacin y sntesis de la solucin, se pueden crear modelos del sistema en un esfuerzo por entender mejor el flujo de datos y de control, la operacin, funciones y contenido de la informacin. Esta modelizacin puede hacerse a travs de: Diagramas de Flujo de Datos Prototipo

Especificacin El anlisis debe, al final, proporcionar una representacin que pueda ser revisada y aprobada por el cliente. Por ello para describir las caractersticas, funciones y atributos del software se escribe una Especificacin Formal de Requisitos.

Revisin Los documentos que especifican los requisitos del software sirven como base para una revisin, lo cual producir quizs, modificaciones en la definicin del proyecto y en la reevaluacin del plan para determinar si las primeras estimaciones siguen siendo vlidas.

El modelo del dominio de los UML es el conjunto de diagramas de estructura esttico con clases, atributos y asociaciones, pero no operaciones. *Construccin* Representa un aspecto de la realidad. Ayuda a los ingenieros de software a gestionar la complejidad. Es mas simple que la realidad.

*Debera* Organizar datos entre objetos y clases. Estructurar datos va herencia y asociaciones. Especificar comportamientos e interfaces pblicas. Describir el comportamiento global. Describir restricciones.

*Esttico: Diagrama de Clase*

Describe tipos de objetos en la aplicacin/dominio. Relaciones estticas entre objetos.

*Contiene* Clases: Objetos , Atributos , y Responsabilidades. Paquetes: Agrupacin de clases. Subsistemas: Agrupacin de clases/paquetes. Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

OBJETO S Representa alguna entidad de la vida real, es decir, alguno de los objetos que pertenecen al problema con el que nos estamos enfrentando, y con los que podemos interactuar. A travs del estudio de ellos se adquiere el conocimiento necesario para, mediante la abstraccin y la generalizacin, agruparlos segn sus caractersticas en conjuntos, estos conjuntos determinan las clases de objetos con las que estamos trabajando.

Un objeto no es un dato simple, sino que puede contener en su interior cierto numero de atributos bien estructurados. Un objeto puede considerarse como una especie de capsula dividida en tres partes: Propiedades Mtodos Relaciones Las propiedades de un objeto pueden ser heredadas a

CLASE
Una clase define la forma y comportamiento de un objeto. Para crear una clase se utiliza la palabra reservada class y a continuacin el nombre de la clase. La definicin de la clase se pone entre las llaves de apertura y cierre. El nombre de la clase empieza por letra mayscula.

Una clase viene descrita por dos tipos de elementos: Atributos (o variables de clase). Describen el estado interno de cada objeto Operaciones (o mtodos). Describen lo que se puede hacer con el objeto, los servicios que

Los atributos pueden ser de cualquiera de los tipos bsicos de Java: boolean, char, byte, short, int, long, float y double.

UML permite asociar tres niveles de proteccin diferentes a cada miembro de la clase: Miembros pblicos (+). Sin ningn tipo de proteccin especial Miembros privados (-). Inaccesibles desde el exterior de la clase Miembros protegidos (#). Similares a los privados aunque se permite su acceso desde las clases descendientes

Relacin entre clases

A nivel de diseo, podemos distinguir entre 5 tipos de relaciones bsicas entre clases de objetos: dependencia, asociacin, agregacin, composicin y herencia

DEPENDENCIA La dependencia es la relacin menos importante. Simplemente refleja que entre dos clases de objetos existe una posible colaboracin temporal con algn propsito.

Una dependencia puede indicar la utilizacin de un objeto de una clase como argumento de una operacin de otra o en su implementacin.

ASOCIACIN La asociacin es la relacin ms importante y ms comn. Refleja una relacin entre dos clases independientes que se mantiene durante la vida de los objetos de dichas clases o al menos durante un tiempo prolongado.

En UML suele indicarse el nombre de la relacin, el sentido de dicha relacin y las cardinalidades en los dos extremos.

AGREGACIN La agregacin es un tipo especial de asociacin donde se aade el matiz semntico de que la clase de donde parte la relacin representa el todo y las clases relacionadas las partes.

COMPOSICIN La composicin es un tipo de agregacin que aade el matiz de que la clase todo controla la existencia de las clases parte. Es decir, normalmente la clase todo crear al principio las clases parte y al final se encargar de su destruccin.

HERENCIA La herencia es un mecanismo de la OOP que permite construir una clase incorporando de manera implcita todas las caractersticas de una clase previamente existente.

Sea una clase A. Si una segunda clase B hereda de A entonces decimos: A es un ascendiente o superclase de B. Si la herencia entre A y B es directa decimos adems que A es la clase padre de B. B es un descendiente o subclase de A. Si la herencia entre A y B es directa decimos adems que B es una clase hija de A.