sábado, 18 de octubre de 2008

Informacion Correcta de la Unidad 3

"Por problemas de subir imagenes  en el blog aqui deja un link para bajar la informacion en formato word con imagenes Aqui!!!''


Esta ingeniería trata con áreas muy diversas de la informática y de las Ciencias de la Computación, tales como construcción de compiladores, Sistemas Operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de Sistema de Información y aplicables a infinidad de áreas (negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet Intranet, etc.).

Una definición precisa aun no ha sido contemplada en los diccionarios, sin embargo se pueden citar las enunciadas por algunos de los más prestigiosos autores:

1 - Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978) 

2 - Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976). 

3 - Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972). 

4 - Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993). 


La ingeniería de software tiene varios modelos o paradigmas de desarrollo en los cuales se puede apoyar para la realización de software, de los cuales podemos destacar a éstos por ser los más utilizados y los más completos:

Modelo en cascada o Clásico (modelo tradicional) 

Modelo en espiral (modelo evolutivo) 

Modelo de prototipos 

Desarrollo por etapas 

Desarrollo iterativo y creciente o Interativo Incremental 

RAD (Rapid Application Development) 


En Ingeniería de software el desarrollo en cascada, también llamado modelo en cascada, es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior.

Un ejemplo de una metodología de desarrollo en cascada es:

1. Análisis de requisitos 

2. Diseño del Sistema 

3. Diseño del Programa 

4. Codificación 

5. Pruebas 

6. Implantación 

7. Mantenimiento 

De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto.

Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

Desarrollo en espiral

El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software. Las actividades de este modelo se conforman en una espiral, cada bucle epresenta un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior

Determinar o fijar objetivos 

Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario. 

Fijar las restricciones. 

Identificación de riesgos del proyecto y estrategias alternativas para evitarlos. 

Hay una cosa que solo se hace una vez: planificación inicial o previa. 

Análisis del riesgo 

Se estudian todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos. 

Desarrollar, verificar y validar (probar) 

Tareas de la actividad propia y de prueba. 

Análisis de alternativas e identificación resolución de riesgos. 

Dependiendo del resultado de la evaluación de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos. Si lo riesgos de protección son la principal consideración, un desarrollo basado en transformaciones formales podría ser el más apropiado. 

Planificar 

Revisamos todo lo hecho, evaluándolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la próxima actividad. 


Modelo de prototipos

En Ingeniería de software el desarrollo con prototipación, también llamado modelo de prototipos que pertenece a los modelos de desarrollo evolutivo, se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido).

Ventajas 

Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. 

También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. 

Inconvenientes 

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. 

En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). 

Desarrollo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultáneamente con las diferentes versiones del código.

Pueden distinguirse las siguientes fases:

Especificación conceptual 

Análisis de requerimientos 

Diseño inicial 

Diseño detallado, codificación, depuración y liberación 

Estas diferentes fases se van repitiendo en cada etapa del diseño


Desarrollo iterativo y creciente

Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada.

Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de trabajo), de los cuales los dos más famosos son el Rational Unified Process y el Dynamic Systems Development Method. El desarrollo incremental e iterativo es también una parte esencial de un tipo de programación conocido como Extreme Programming y los demás frameworks de desarrollo rápido de software.

Desarrollo rápido de aplicaciones

Rapid application development (RAD), es un proceso de desarrollo de software, en inglés: software development process, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE (Computer Aided Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución.

Hoy en día se suele utilizar para referirnos al desarrollo rápido de GUIs tal como Glade, o IDEs de desarrollo completas como Delphi, Foxpro o Anjuta. Uno de los programas más usados para hacer aplicaciones rápidamente es el Visual Basic


Ventajas y desventajas 

El desarrollo rápido tiene dos ventajas primarias:

Velocidad del desarrollo: Los aumentos de la velocidad son debido al uso de la herramienta CASE. 

Calidad: según lo definido por el RAD, es el grado al cual un uso entregado resuelve las necesidades de usuarios así como el grado al cual un sistema entregado tiene costes de mantenimiento bajos. El RAD aumenta calidad con la implicación del usuario en las etapas del análisis y del diseño. 

El RAD tiene dos desventajas primarias:

Características reducidas. 

Escalabilidad reducida: debido a que el RAD se desarrolló como prototipo. 

Diagrama de Flujo de Datos

Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es una representación gráfica del "flujo" de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y la entidades externas. Este contexto a nivel de DFD se "explotó" para mostrar más detalles del sistema que se está modelando.


Los datos de diagramas de flujo fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos(DFDs) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado puede determinarse a través de un diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificación de los datos de la transacción en el modelo de datos.


Componentes de un Diagrama de Flujo de Datos (DFD) según la notación de Yourdon y DeMarco.


Los diagramas derivados de los procesos principales se clasifican en niveles, los cuales son:

Nivel 0: Diagrama de contexto. 

Nivel 1: Diagrama de nivel superior. 

Nivel 2: Diagrama de detalle o expansión

Características de los niveles 

Diagrama de Contexto: Nivel 0 

En el diagrama de contexto solo se dibuja el proceso principal y los flujos entre este y sus entidades externas.

Diagrama de Nivel Superior: Nivel 1 

En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no pueden interrelacionarse directamente, sino que entre ellos siempre debe existir algun almacenamiento o entidad externa que los una.

Diagrama de Detalle o Expansión: Nivel 2 

A partir del nivel 2 de detalle, los procesos pueden interrelacionarse directamente, sin necesidad de almacenamiento que los una. Cabe destacar que en el nivel 1 y 2 siempre los procesos deben tener las entradas y las salidas dadas en el diagrama de contexto.

Nota: Diagrama de nivel 2 (o superior) en la fotografía. Es de nivel >= 2, y no de nivel 1 porque en el nivel 1 no se permiten las interconecciones entre procesos, como puede verse entre el proceso 2 y 3.


Diccionario de datos

Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.

Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño del proyecto.

Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.

En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.

Ejemplo 

 ________________________________________________________

|                                                        |

| Nombre Flujo dato: Solicitud/consulta                  |

| Seudónimo: -proyecto corporacion iberoAmricana--      

| Composición:publicidad                                           

|  [Nombre corporacion IberoAmericana]                                  

|  + ([Rut 


                                 

|  + (ing sistemas)                                            

|  + [manejo de la publicidad]                               

|  + [plasmar proyecto/terminacion proyecto]                    

| Obs.: solo se eleva una petición no intercambia datos. |

|________________________________________________________|

Definiciones 

Una definición de un dato se introduce mediante el símbolo “=”; en este contexto el “=” se lee como “está definido por”, o “está compuesto de”, o “significa”. Para definir un dato completamente, la definición debe incluir:

El significado del dato en el contexto de la aplicación. Esto se documenta en forma de comentario. 

La composición del dato, si es que está compuesto de otros elementos significativos. 

Los valores que el dato puede tomar, si se trata de un dato elemental que ya no puede ser descompuesto. 

Diccionario de datos (DD) Este elemento del enfoque de base de datos es el conjunto centralizado de atributos lógicos que especifican la identificación y caracterización de los datos que se manejan en la BD. La BD contiene el valor de los datos, el DD contiene meta datos, es decir los atributos lógicos de dichos datos.

Datos elementales 

Son aquellos para los cuales no hay una descomposición significativa. Por ejemplo, puede ser que no se requiera descomponer el nombre de una persona en primer-nombre, apellido-materno y apellido-paterno; esto depende del contexto del sistema que se esté modelando. Cuando se han identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripción que describa el significado del dato. En el caso de que el dato tenga un nombre significativo, se puede omitir la descripción, sin embargo; es importante especificar las unidades de medida que el dato puede tomar.

Ejemplo: Peso = * peso del paciente al ingresar al hospital *

unidad: kilo, rango:2-150 * 

Altura = * unidad: cm, rango: 100-200 * Sexo = * valores : [F|M] * APGR Ingeniería de Software I Análisis Estructurado 24

Datos opcionales 

Un dato opcional es aquel que puede o no estar presente como componente de un dato compuesto. Ejemplo: Dirección = calle + número + (ciudad) + (país) + (código-postal)

Selección 

Indica que un elemento consiste de exactamente una opción de un conjunto de alternativas. Ejemplos:

Sexo = [ Femenino | Masculino ]

Tipo-de-cliente = [ Gubernamental | Académico | Industria | Otros ]

Iteración 

Se usa para indicar ocurrencias repetidas de un componente en un elemento compuesto.

Ejemplo: Orden-de compra = nombre-cliente + dirección-de-envío + {artículo} significa que una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y cero o más ocurrencias de un artículo.

Ejemplo: Se pueden especificar límites superiores e inferiores a las iteraciones. Orden-de compra = nombre-cliente + dirección-de-envío + 1{artículo}10 significa que una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y de 1 a 10 artículos.

APGR Ingeniería de Software I

Análisis Estructurado

25

Ejemplos de iteraciones con límites:

a = 1{b}

a = {b}10

a = 1{b}10

a = {b}

EJEMPLO REGISTRO DE EMPLEADOS = {Registro del empleado}

REGISTRO DE TIEMPOS DEL EMPLEADO = {Registro de tiempos del empleado}

Registro del empleado =

* Datos de cada empleado*

Número de empleado + Información personal + Información de pago + Información de pago actual + Información anual

Registro de tiempos del empleado = Número de empleado + Nombre del empleado + Horas trabajadas

Cheque de pago del empleado = Número de empleado + Nombre de empleado + Dirección + Cantidades del pago actual + 5

Produce el cheque de pago del empleado

REGISTRO DE TIEMPOS DEL EMPLEADO

Empleado

Cheque de pago del empleado

Registro del empleado

Registro de tiempos del empleado

REGISTRO DE EMPLEADOS

APGR Ingeniería de Software I

Análisis Estructurado

26

El DD provee información del DER. En general, las instancias del DER corresponden a los almacenes de datos de los DFD. EJEMPLO: CLIENTES = {cliente}

cliente = nombre-cliente + dirección + número-teléfono

compra = * asociación entre un cliente y uno o más artículos *

nombre-cliente + 1{id-artículo + cantidad-artículos}

ARTÍCULOS = {artículo}

artículo = id-artículo + descripción

En el ejemplo anterior, cliente es la definición de un tipo de objeto (entidad) y una instancia del almacén de datos CLIENTES. La llave de cliente es el atributo nombre-cliente, el cual diferencia una instancia de otra. El signo @ es usado para indicar los campos llave, o bien estos campos llave se subrayan.


Descomposición en Procesos 

Una vez que se ha elegido el modelo de proceso, la estructura común de proceso (ECP) se adapta a él. En todos los casos, la ECP (comunicación con el cliente, planificación, análisis de riesgo, ingeniería, construcción, entrega y evaluación del cliente) puede adaptarse al paradigma. Funcionara para modelos lineales, para modelos interactivos e increméntales, para modelos de evolución e incluso para modelos concurrentes o de ensamblaje de componente. La ECP es invariable y sirve como base para todo el trabajo de software realizado por una organización.

La descomposición de trabajo empieza cuando el gestor del proyecto pregunta: "¿cómo vamos a realizar esta actividad ECP?". Por ejemplo, un pequeño proyecto, relativamente simple, requiere las siguientes tareas para la actividad de comunicación con el cliente:

1.- Desarrollar una lista de aspectos que se han de clasificar.

2.- Reunirse con el cliente para resolver los aspectos que se han de clasificar.

3.- Desarrollar conjuntamente una exposición del ámbito del proyecto.

4.- Revisar el alcance del proyecto con todos los implicados.

5.-Modificar el alcance del proyecto cuando se requiera.

Estos acontecimientos pueden ocurrir en un periodo de menos de 48 horas. Representa una descomposición del problema apropiado para proyectos pequeños relativamente sencillos.

Ahora, consideremos un proyecto mas complejo que tenga un ámbito mas amplio y un mayor impacto comercial. Un proyecto como ese podría requerir las siguientes tareas para la actividad de comunicación con el cliente:

1. Revisar la petición del cliente. 

2. Planificar y programar una reunión formal con el cliente. 

3. Realizar una investigación para definir soluciones propuestas y enfoques existentes. 

4. Preparar un "documento de trabajo" y una agenda par la reunión formal. 

5. Realizar una reunión. 

6. Desarrollar conjuntamente mini-especificaciones que reflejan la información, función y características de comportamiento de software. 

7. Revisar todas las mini-especificaciones para comprobar su corrección, su consistencia y sus ambigüedades. 

8. Ensamblar las mini-especificaciones en un documento de alcance del proyecto. 

9. Revisar ese documento general con todo lo que pueda afectar. 

10. Modificar el documento de alcance del proyecto cuando se requiera


El Enfoque Orientado a Objetos 

Introducción 

El desarrollo de sistemas orientados a objeto es nuevo para muchos de nosotros. Ser nuevo en esto supone muchos cambios. Entre ellos está el proceso de planificación y dirección del proyecto. La mayoría de nosotros ha desarrollado proyectos antes. En aquellos proyectos trabajábamos con los usuarios para saber cuál era el sistema y cómo era que debían hacerse las cosas. Nosotros diseñábamos los programas y escribíamos las aplicaciones. Entonces, ¿qué tiene de especial la orientación a objetos? 

Uno de los aspectos de la orientación a objetos es el hecho de que es relativamente nuevo de usar. Debido a esta novedad estamos casi constantemente encontrando barreras de ideas a superar. Este escrito está diseñado para exponer uno de los muchos aspectos del desarrollo orientado a objetos, el análisis y diseño y para ayudarnos a encontrar el “sendero en la jungla”. El método de análisis y diseño que vamos a examinar es llamado Enfoque iterativo, toma este nombre porque todo el proceso de desarrollo es logrado a través de una serie de iteraciones donde cada una abarca el proceso entero para el análisis a través de pruebas. Durante cada una de estas iteraciones somos capaces de retroalimentar la información de las primeras etapas del proyecto. 

¿Cuándo debemos usar un proceso interactivo? 

Martin Fowlr, en su libro “UML Distilled" (disponible en www.amazon.com), dice”Debe utilizar un desarrollo iterativo solo en los casos en que desee obtener éxito” El no está exagerando. Nadie puede asegurar completamente ninguna fase del ciclo de desarrollo en un simple paso. Estos son simplemente muchos detalles a los que dirigirse en cada etapa de desarrollo. La metodología puede ser usada tal que no solo permita revisar las etapas anteriores sino que también las complemente. La metodología iterativa es justo eso. Requiere que grandes proyectos sean partidos en pequeñas piezas y que cada pieza sea desarrollada mediante un proceso iterativo de análisis, diseño, implementación y pruebas. 

¿Por qué hacer iteraciones? 

Las iteraciones nos permiten enfocar un subconjunto del proyecto completo de tal forma que lo podemos terminar en detalle. Frecuentemente vamos a descubrir nuevos problemas y requerimientos durante el proceso de creación de uno de sus subsistemas. Estos nuevos descubrimientos pueden ser fácilmente incorporados en una iteración posterior sin desechar lo que se ha avanzado hasta entonces.

Este proceso nos permite probar cada subsistema independientemente y asegurar su propia funcionalidad. Esto significa que cuando alcancemos la etapa final del desarrollo - la integración entre los subsistemas como un todo - podremos concentrarnos en la integración sabiendo que cada subsistema está ya completamente probado.

Trabajando lo más temprano posible con los aspectos de alto riesgo para el proyecto, seremos capaces de reducir la influencia de estos riesgos en el cronograma completo del proyecto.

Durante la implementación de los subsistemas nuevos casos de uso pueden ser descubiertos. Estas situaciones nuevas pueden ser planificadas para la siguiente iteración. 

¿Qué es el enfoque iterativo? 

El enfoque iterativo no es nada nuevo ni revolucionario. Muchos de nosotros hemos creado sistemas por esta vía hace mucho tiempo. Martin Fowler clasifica las fases de un proyecto iterativo como Iniciación, Elaboración, Construcción y Transición. Cada una de estas fases constituye un punto diferente en la continuidad del proyecto hasta el final del mismo. 

El proyecto comienza con la fase de Iniciación. Durante esta fase, la que discutiremos con más detalle más adelante, vamos a invertir un tiempo explicándonos qué es el proyecto y la mejor idea de cómo hacerlo. Al final de la fase de iniciación debemos tener una idea bastante acertada del alcance del proyecto. Los detalles no serán obtenidos; pero la visión general del sistema está aquí. En este punto podemos hacer nuestro primer corte del proyecto en piezas. Estas piezas deben estar suficientemente encapsuladas que permitan crearlas independientemente. Cada una de estas piezas satisface un subconjunto de requerimiento del sistema completo.

La mayor ventaja de este método es que puede identificar el riesgo involucrado con el proyecto y tenerlo en cuenta en la dirección del mismo. Esto nos ayuda a evitar, que conociendo todas las cosas que podrían ir mal haya que esperar a que empiecen a fallar.

Estos riesgos pueden ser esparcidos por todo el proyecto y continuar teniéndolos en cuenta. 

Categorías de riesgo 

Los riesgos que enfrentamos en el desarrollo del proyecto los podemos dividir en cuatro categorías. Estas categorías son: riesgos de requerimiento, riesgos tecnológicos, riesgos de habilidades y riesgos políticos. Cualquier proyecto con un alcance relativo tendrá algunos riesgos asociados con cada una de estas características. Ignorar o negar la presencia de estos riesgos significaría matar el proyecto. Estos riesgos pueden ser solo superados si no son bien manejados. Manejar los riesgos requiere de conocer cual es el riesgo y tener un plan para lidiar con ellos. 


Análisis Objetos  y Diseño Objetos

Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.

En éste método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por ejemplo, el lenguaje únificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.

El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño orientado a objetos

Análisis de la Estructura de Objetos.

El análisis de la estructura de objetos (AEO) define las categorías de los objetos que percibimos y las formas en que los asociamos. 

  

Objetos y Tipos de Objetos.

En el análisis se trata de identificar los tipos de objeto más que los objetos individuales en un sistema. Los tipos de objetos se definen en base a la comprensión del analista de nuestro mundo. Un objeto puede categorizarse de variadas formas. 


Representación para Tipo de Objeto (Persona).

Asociaciones de Objetos.

Es importante modelar la forma como los objetos se asocian entre sí. Además es necesario identificar el significado de la asociación y la cantidad de objetos con los que un objeto dado puede y debe asociarse (cardinalidad). 


Jerarquías de Generalización.

Una de las vías de sentido común por las que el hombre organiza su volumen de conocimiento es el de las jerarquías, de lo más general a lo más específico. 

 En las jerarquías se habla de subtipo o especialización de un supertipo o generalización. En el caso anterior, persona es el supertipo para Empleado y Estudiante, que son sus subtipos. Por otra parte, Empleado es el supertipo para los subtipos Ejecutivo y Vendedor. Los subtipos (niveles inferiores de la jerarquía) heredan las características de sus supertipos, además, cada instancia de un tipo de objeto lo es también de sus supertipos. 

  

Jerarquías Compuestas.

Un objeto se denomina complejo si está formado por otros. Las jerarquías Compuestas permiten realizar agregaciones de objetos. 


Un objeto del tipo edificio se compone de a lo menos un objeto del tipo piso. A su vez un objeto del tipo piso se compone de a lo menos un objeto del tipo pasillo, podría tener varios (o ninguno) objetos del tipo baño y oficina. 

Diagramas de relación entre los objetos.

Los tipos de objetos están relacionados con otros tipos de objeto. Por ejemplo, un empleado trabaja en una sucursal, o un cliente realiza un pedido de varios productos. 

Un objeto del tipo cliente puede ordenar muchos objetos del tipo pedidos, y un objeto del tipo pedido es ordenado por un y sólo un objeto del tipo cliente. Un objeto del tipo producto está en muchos o ningún objeto del tipo pedido, mientras que un objeto del tipo pedido tiene al menos un objeto del tipo producto. 

  

Esquemas de Objetos.

La comprensión de un modelo suele ser más sencilla si los tipos de objetos y relaciones se presentan mediante un diagrama de relación entre objetos; los supertipos y subtipos se presentan en un diagrama de jerarquías de generalización y las estructuras compuestas en un diagrama compuesto. Sin embargo, para los usuarios más sofisticados puede ser útil presentarlo todo en un mismo diagrama, el que se denomina esquema de objetos.

.