Enfoque Estructura do

4/12/12

1: Modelado de Procesos.
Haga clic para modificar el estilo de subttulo del patrn Zavala Herquinio, kelly

4/12/12

Definicion
Elmodelado de procesos, as como su nombre lo indica, tiene 2 aspectos que lo definen: el modelado y los procesos. Frecuentemente, los sistemas, conjuntos de procesos y subprocesos integrados en una organizacin. Un modelo es una representacin de una realidad compleja. Modelar es desarrollar una descripcin lo ms exacta posible de un sistema y de las actividades llevadas a cabo en l. Cuando un proceso es modelado, con ayuda de una representacin grfica (diagrama de proceso), pueden apreciarse con facilidad las interrelaciones existentes entre distintas actividades, analizar cada actividad, definir los puntos de contacto con otros procesos, as como identificar los subprocesos comprendidos. Al mismo tiempo, los problemas existentes pueden ponerse de manifiesto claramente dando la oportunidad al inicio de acciones de mejora.

4/12/12

Representa cin

4/12/12

2: MODELADO DEL FLUJO DE LA INFORMACIN

Las transformaciones que se aplican a los datos son funciones que debe realizar un programa.
Es la manera en que DESCRIPCIN

se representa la REPRESENTACIN forma en que los 4/12/12

 REPRESENTACIN

MODELADO DEL FLUJO DE LA INFORMACIN

DFD
Un

circulo representa un proceso o transformacin que se aplica a los datos y los cambia de alguna forma. Representa informacin almacenada y que utiliza el software. Un rectngulo representa a un elemento del sistema ( por ejemplo un hardware, una persona, un programa ) o un 4/12/12 sistema que produce o recibe

4/12/12

Modelo de Flujo de Informacin de Contexto

4/12/12

Modelo de Flujo de Informacin de Nivel 1

4/12/12

Modelo de Flujo de Informacin de Nivel 2

4/12/12

3: Analisis del Sistema

El Anlisis se refiere al extremo inicial de un proyecto de desarrollo de sistemas, durante el tiempo en que los requisitos del usuario son definidos y documentados. Haga clic para modificar el estilo de subttulo del patrn

4/12/12

Anlisis de Requisitos.
El

anlisis de requisitos es el proceso de estudio de las necesidades de los usuarios para llegar a una definicin de los requisitos del sistema de hardware o de software; as como su estudio y refinamiento. Tras haber estudiado las posibilidades con las que se cuenta para el desarrollo del sistema, as como sus limitaciones, se puede establecer una lista ms firme de requisitos, tanto a nivel funcional como no funcional.

4/12/12

Dominio de la Informacin
El

software se construye para procesar datos, para transformarlos es decir, para aceptar datos de entrada, manipularlos y producir informacin de salida. Pero el software tambin procesa acontecimientos, que controlan al sistema y no es ms que un dato binario, tal como un sensor que enva al software una seal de alarma. Por tanto, los datos ( nmeros, caracteres, imgenes, sonidos, etc. ) y el control ( acontecimientos ) son parte del dominio de la informacin.
4/12/12

Dominio de la Informacin
1.

Contenido de la Informacin

2.

Flujo de la Informacin

3.

Estructura de la Informacin

4/12/12

Estructura del Modelo de Anlisis

El

modelo de anlisis debe cumplir tres objetivos primarios: 1: Describe lo que requiere el cliente 2: Establecer una base para la creacin de un diseo de software 3: Definir un conjunto de requisitos que puedan validarse una vez construido el software

4/12/12

Modelo de Datos
un esquema terico de un sistema o realidad compleja que se elabora para facilitar su comprensin y estudio. Es una representacin de los aspectos esenciales de una realidad compleja de acuerdo a un criterio Todo modelo es necesariamente una simplificacin de la realidad Por qu modelar? Para facilitar el estudio y analizar el comportamiento de un SI(sistema de informacin), y sus componentes
Es

4/12/12

Objetos, Atributos, Relaciones

Lasentidadesson

los objetos principales sobre los que se debe recoger informacin y generalmente denotan personas, lugares, cosas o eventos de inters. Las entidades aparecen reflejadas en el enunciado habitualmente como nombres. Grficamente se simbolizan con un rectngulo.

4/12/12

 Losatributosse

utilizan para detallar las entidades asignndoles propiedades descriptivas tales como nombre, color y peso. No solo es posible especificar atributos en las entidades sino tambin en las relaciones. Los atributos tambin aparecen reflejados en el enunciado, generalmente, como nombres. Las entidades pueden clasificarse por la fuerza de sus atributos identificadores, es decir, por su dependencia o no dependencia respecto a otras entidades. Las entidades fuertes tienen existencia propia, es decir, poseen identificadores internos que determinan de manera nica la existencia de 4/12/12

 Lasrelacionesrepresentan

asociaciones en el mundo real entre una o ms entidades. Las relaciones se caracterizan por su nombre, el grado (nmero de entidades que participan en la relacin), el tipo de cardinalidad (nmero mximo de ejemplares de una entidad asociados a una combinacin de ejemplares de las otras entidades de la relacin, que pueden ser 1 N). Grficamente las relaciones se simbolizan con un rombo.

4/12/12

Una-Una (1:1), significa que cada entidad de la primera relacin se va a relacionar con una entidad de la segunda relacin y viceversa. P. ejemplo. r1-r2 Una-Muchas (1:N), las entidades de la relacin r1 se pueden relacionar con varias entidades de la relacin r2. Pero las entidades de la relacin r2 solo pueden asociarse con una entidad de r1.

r2P. ejemplo. r1
*

Muchas-Una (N:1), las entidades de r1 4/12/12 solo pueden asociarse con una entidad de

Diagrama Entidad Relacion

Elaborado

por Peter Chen en 1976. En este modelo se presenta la vista unificada de los datos, centrndose en la estructura lgica y abstracta de los datos, como representacin del mundo real, con independencia de consideraciones del mundo fsico. Un modelo Entidad-Relacin tiene los siguientes elementos: Entidades una persona, lugar, cosa, concepto, suceso, real o abstracto de inters para la empresa. Es aquel objeto acerca del 4/12/12 cual queremos almacenar informacin en la

Modelo Funcional y Flujo de la Informacin

El modelo funcional describe los comportamientos y operaciones de los objetos. El modelo funcional muestra la dependencia de datos en el sistema. El modelo funcional describe la computacin dentro del sistema, cmo los valores de salida se derivan de los valores de entrada, sin importar el orden en que son computados. El modelo funcional consiste de mltiples diagramas de flujo de datos.
4/12/12

 El

diagrama de flujo de datos ( DFD ) es una tcnica grfica que representa el flujo de la informacin y las transformaciones que se aplican a los datos al moverse desde la entrada a la salida. notacin bsica para construir DFDs es la siguiente:

La

4/12/12

 Un

rectangulo representa a un elemento del sistema ( por ejemplo un hardware, una persona, un programa ) o un sistema que produce o recibe informacin que es transformada por el software. circulo representa un proceso o transformacin que se aplica a los datos y los cambia de alguna forma.

Un

4/12/12

 La

flecha representa a un elemento o una coleccin de elementos de datos.

Representa

informacin almacenada y que utiliza el software.

4/12/12

Modelado de comportamiento
El

diagrama de transicin de estados DTE representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado. Un estado es un modo observable de comportamiento, por ejemplo monitoreando, comprobando, calculando, etc. Cada estado representa un modo de comportamiento y el DTE indica cmo se mueve el sistema de un estado a otro.

4/12/12

Diccionario de datos
La

notacin bsica para crear los DERs, DFDs y DTEs no son suficiente para describir los requisitos del software, por ello el mtodo de Anlisis Estructurado se complementa con el Diccionario de Datos, en el cual se define el contenido de la informacin o en otras palabras se describen los datos del sistema. Un Diccionario de Datos es una lista con todos los detalles y descripciones de los elementos incluidos en los Diagramas de Flujo de Datos que describen al sistema.
4/12/12

El diccionario de datos debe contener:

1.

Descripcin de los datos 2. Descripcin de los 3. Descripcin de las 4. Descripcin de los 5. Descripcin de los

almacenamientos de procesos estructuras de datos elementos de datos flujos de datos

4/12/12

4: DISEO DEL SISTEMA (DESCRIPCIN)

Haga clic para modificar el estilo de subttulo del CONCEPTOS: patrn

4/12/12

ABSTRACCION

Definicin: Separar por medio de una operacin intelectual las cualidades de un objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia o nocin [RAE, 2001] La representacin de las caractersticas esenciales de algo sin incluir antecedentes o detalles irrelevantes [Graham, 1994] La nocin psicolgica de abstraccin permite concentrarse en un problema a un nivel de generalizacin independiente de los detalles de nivel inferior; la abstraccin tambin permite trabajar con conceptos y trminos que son familiares en el entorno del problema sin tener que transformarlos en una estructura poco familiar [Wasserman, 1983]
4/12/12

ABSTRACCION
Ventajas:

Define y refuerza las restricciones de acceso Facilita el mantenimiento y la evolucin de los sistemas software Reduce los efectos laterales Limita el impacto global de las 4/12/12 decisiones de diseo locales

REFINAMIENTO

Similitud con el procedimiento de particin y refinamiento del anlisis de requisitos

La diferencia est en el nivel de detalle, no en el enfoque

El

refinamiento es un procedimiento de elaboracin

Funcin descrita a un nivel conceptual Refinamientos sucesivos que incorporan ms detalles

Gestiona

la complejidad dividiendo problemas grandes en problemas pequeos

Permite que personas diferentes puedan trabajar con cada parte Permite la especializacin de los ingenieros del software Cada componente individual es ms pequeo y, por tanto, su comprensin es ms sencilla Las partes se pueden remplazar o cambiar sin tener que 4/12/12 remplazar o cambiar de forma generalizada el resto de las

MODULARIDAD
Propiedad

de un sistema que ha sido descompuesto en un conjunto de mdulos coherentes e independientes El software se divide en componentes con nombres y ubicaciones determinados, que se denominan mdulos y que se integran para satisfacer los requisitos del proveedor.

4/12/12

MODULA La modularidad RIDAD del

software facilita el desarrollo del mismo, pero hasta un cierto lmite, porque si llegramos a dividir el problema en infinitos mdulos, los mdulos tendran una complejidad y un esfuerzo mucho menor, pero crecera el coste asociado a la creacin de

4/12/12

ARQUITECTURA DEL SOFTWARE

La

arquitectura del software alude a la estructura global del SW y a las formas en que la estructura proporciona la integridad conceptual de un sistema La arquitectura del SW es la estructura jerrquica de los componentes del programa (mdulos), la manera en que los componentes interactan y la estructura de datos que van a utilizar los componentes.

4/12/12

ARQUITECTURA DEL SOFTWARE

4/12/12

JERARQUA DE CONTROL
La

jerarqua de control, denominada tambin estructura del programa, representa la organizacin de los componentes del programa (mdulos) e implica una jerarqua de control. No representa los aspectos procedimentales del software, ni se puede aplicar necesariamente a todos los estilos arquitectnicos.

4/12/12

JERARQUA DE CONTROL

4/12/12

PARTICIN ESTRUCTURAL
La

estructura de un programa debe partirse horizontal y verticalmente La particin horizontal define ramas separadas de la jerarqua modular para cada funcin principal del programa

Mdulos de control Enfoque entrada/proceso/salida

Beneficios

de la particin horizontal

Proporciona software ms fcil de probar Lleva a un software ms fcil de mantener Propaga menos efectos secundarios Proporciona software ms fcil de ampliar
4/12/12 en contra de la particin horizontal

Puntos

PARTICIN ESTRUCTURAL
Particin vertical o descomposicin en factores (factoring) La particin vertical expresa que el control, toma de decisiones, y el trabajo se distribuyan de forma descendente en la arquitectura del programa Los mdulos de nivel superior deben realizar funciones de control y poco trabajo de procesamiento Los mdulos que residen en la parte baja de la arquitectura deben de ser los que realicen las tareas de entrada, clculo y 4/12/12 salida

PARTICIN ESTRUCTURAL

4/12/12

PARTICIN ESTRUCTURAL

4/12/12

ESTRUCTURA DE DATOS
La

estructura de datos e una representacin de la relacin lgica entre elementos individuales de datos . Como la estructura de la informacin afectara invariablemente al diseo procedimental final, la estructura de datos es tan importante como la estructura de programa para la representacin de la arquitectura de software

4/12/12

PROCEDIMIENTO (DEL SOFTWARE)

La

estructura del programa define la jerarqua de control sin tener en consideracin la secuencia de proceso y de decisiones. El procedimiento de software se centra en el procesamiento de cada modulo individualmente. El procedimiento debe proporcionar una especificacin precisa de procesamiento, incluyendo la secuencia de sucesos , los puntos de decisin exactos, las operaciones repetitivas e incluso la estructura , 4/12/12 organizndole datos.

OCULTAMIENTO DE LA INFORMACIN
Los

mdulos de un sistema deben disearse de modo que la informacin contenida en ellos sea inaccesible a todos aquellos mdulos que no necesiten tal informacin David Parnas, 1970

Los mdulos debern especificarse y disearse de manera que la informacin (procedimientos y datos) que est dentro de un mdulo sea inaccesible a otros mdulos que no necesiten esa informacin

4/12/12

OCULTAMIENTO DE LA INFORMACIN
El

ocultamiento de la informacin es un buen medio para conseguir abstraccin Restricciones de acceso

Detalle procedimental dentro del mdulo Estructura de datos local empleada por el mdulo

El

diseador de cada mdulo debe seleccionar un subconjunto de las propiedades del mdulo como informacin oficial del mdulo, para ponerlas a disposicin de los autores de mdulos o de mdulos clientes
4/12/12

OCULTAMIENTO DE LA INFORMACIN
Las

decisiones de diseo sujetas a cambio deben ocultarse detrs de interfaces abstractas

Las aplicaciones software han de comunicarse nicamente a travs de interfaces bien definidas La interfaz de un mdulo debe revelar lo menos posible de su funcionamiento interno Intercambio de mdulos mientras que se mantengan intactas las interfaces Ventajas a la hora de hacer cambios

Ocultacin

significa que se puede conseguir una modularidad efectiva definiendo un conjunto de mdulos independientes que se 4/12/12 comunican intercambiando la informacin

COHESION
La cohesin hace referencia a la forma en que agrupamos unidades de software(mdulos, subrutinas...) en una unidad mayor. Por ejemplo: la forma en que se agrupan funciones en una biblioteca de funciones o la forma en que se agrupan mtodos en una clase. Tipos de cohesin * Cohesin funcional: Los elementos de la unidad de software estn relacionados en el desarrollo de una nica funcin. Es decir, las unidades de software trabajan juntas con un mismo fin. En general, es el criterio de agrupacin ms deseable. Probablemente haya entre las unidades un acoplamiento relativamente alto, por lo tanto es conveniente que estn juntas. * Cohesin secuencial: Una unidad de software realiza distintas tareas en secuencia, de forma que las entradas de cada tarea son las salidas de la tarea anterior. En otras palabras, se agrupan las unidades que cumplen que los resultados o salidas que produce una sirven como entrada para que la prxima contine trabajando. * Cohesin comunicacional o de datos: La unidad de software realiza actividades paralelas usando los mismos datos de entrada y salida. En otras palabras, cuando todas las unidades agrupadas trabajan sobre el mismo conjunto de datos. * Cohesin procedimental: La unidad de software tiene una serie de funciones relacionadas por un procedimiento efectuado por el cdigo. Es similar a la secuencial, pero incluyendo el paso de controles. * Cohesin lgica: Cuando las unidades de software agrupadas realizan un trabajo en una misma categora lgica, pero no necesariamente tienen relacin entre s. Por ejemplo: bibliotecas de funciones matemticas, slo se agrupan porque realizan clculos matemticos, pero no tienen necesariamente relacin entre ellas. * Cohesin temporal: Los elementos de la unidad de software estn implicados en actividades relacionadas con el tiempo. En otras palabras, se agrupan unidades de software que tienen que ejecutarse ms o menos en el mismo perodo de tiempo, sin que haya otro tipo de relacin entre ellas. En general debe evitarse. * Cohesin casual o coincidente: Los elementos de la unidad de software contribuyen a las actividades relacionndose mutuamente de una manera poco significativa. En otras palabras, es cualquier criterio que no caiga dentro de los anteriores. Este tipo de cohesin viola el principio de independencia y de caja negra de las unidades de software, por lo tanto debe evitarse.

4/12/12

ACOPLAMIENTO
El acoplamiento informtico indica el nivel de dependencia entre las unidades de software de un sistema informtico, es decir, el grado en que una unidad puede funcionar sin recurrir a otras; dos funciones son absolutamente independientes entre s (el nivel ms bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas estn desacopladas. Un ejemplo simple de acoplamiento es cuando un componente accede directamente a un dato que pertenece a otro componente. En ese caso, el resultado del comportamiento del componente A depender del valor del componente B, por lo tanto, estn acoplados. Tipos de acoplamiento

Acoplamiento normal: una unidad de software llama a otra de un nivel inferior y tan solo intercambian datos (por ejemplo: parmetros de entrada / salida). Dentro de este tipo de acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien las unidades de software. Para ms informacin ver Acoplamiento normal. Acoplamiento externo: las unidades de software estn ligadas a componentes externos, como por ejemplo dispositivos de entrada / salida, protocolos de comunicaciones, etc. Acoplamiento comn: dos unidades de software acceden a un mismo recurso comn, generalmente memoria compartida, una variable global o un fichero. Acoplamiento de contenido: ocurre cuando una unidad de software necesita acceder a una parte de otra unidad de software.

4/12/12

DISEO DE DATOS
El diseo de datos consiste en descubrir y la definir completamente de los procesos y caractersticas de los datos de la aplicacin. El diseo de datos es un proceso de perfeccionamiento gradual que abarca desde la cuestin ms elemental, "Qu datos requiere la aplicacin?", hasta los procesos y estructuras de datos precisos que proporcionan dichos datos. Si el diseo de datos es bueno, el acceso a los datos de la aplicacin ser rpido y fcil de mantener, y podr aceptar sin problemas las futuras mejoras de los datos.

4/12/12

Diseo de Arquitectura
Define la relacin entre los principales elementos estructurales del programa. Se obtiene a partir del modelo de anlisis y de la interaccin de subsistemas definidos dentro del modelo de anlisis. La arquitectura de software nos proporciona una visin global del sistema a construir. Marca decisiones de diseo tempranas y proporciona el mecanismo para evaluar los beneficios de las estructuras de sistema alternativas.

4/12/12

FLUJO DE TRANSFORMACION
La

informacin debe introducirse y obtenerse del software en forma de mundo exterior, la informacin entra en el sistema a lo largo de caminos que transforman los datos externos a un formato interno. Estos caminos se identifican como flujo de entrada. La informacin entrante se pasa a travs de un centro de transformacin y empieza a moverse a lo largo de caminos que ahora conducen hacia fuera del software. Los datos que se mueven a lo largo de este camino se denominan flujo de salida.
4/12/12

FLUJO DE TRANSACCION
El

flujo de transaccin se caracteriza por datos que se mueven a lo largo de un camino de entrada que convierte la informacin del mundo exterior en una transaccin. La transaccin se evala y, basndose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de accin. El centro de flujo de informacin del que parten muchos de los caminos de accin se denomina centro de transaccin.

4/12/12

Diseo de interfaz
Describe

como se comunica el software consigo mismo, con los sistemas que operan con l y con los operadores que lo emplean. Los diagramas de flujo de datos y control proporcionan la informacin necesaria para el diseo de la interfaz.

4/12/12

Diseo procedimental
Transforma

elementos estructurales de la arquitectura del programa en una descripcin procedimental de los componentes del software. Se obtiene a partir de la especificacin del proceso, la especificacin del control y el diagrama de transicin de estados

4/12/12

Enfoque Orientado a Objetos

Haga clic para modificar el estilo de subttulo del patrn

4/12/12

 1.

Conceptos 2. Anlisis del Sistema Descripcin 3. Diseo del Sistema descripcin

4/12/12

Objeto
Primera

vez propuesto a fines de los aos 70 y convertida en paradigma en los aos 90. Un objeto es aquello que tiene estado (propiedades ms valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los dems objetos). Conjunto de objetos (Clase).

4/12/12

Clase
Conjunto

de objetos que comparten una estructura y comportamiento en comn Plantilla o prototipo para crear objetos de ese tipo, la cual contiene las caractersticas y acciones comunes del objeto

4/12/12

Atributos
Es una especificacin que define una propiedad de un objeto diferencindolo as de los otros objetos. Describen la clase o el objeto de alguna manera, la cual esta definida por un dominio(conjunto de valores especficos).

4/12/12

Mtodos
un

mtodo son las operaciones asociadas a un objeto. Por ejemplo, la casa puede estar cerrada o abierta (siendo "estadoDeLaPuerta" un atributo con posibles valores "abierta" o "cerrada"), y posee un mtodo "abrirPuerta" o "cerrarPuerta"

4/12/12

Mensajes
mensajes son el medio a travs del cual interactan los objetos. Los mensajes y los mtodos son dos caras de la misma moneda LOS METODOS SON LOS PROCEDIMIENTOS INVOCADOS CUANDO UN OBJETO RECIBE UN MENSAJE ( Greg Voss) tres partes que componen un mensaje: 1. El objeto al cual se manda el mensaje (TuBicicleta). 2. El mtodo o funcin miembro que debe ejecutar (CambiarDeMarcha).
4/12/12

Los

Encapsulamiento
Es

empaquetar o proteger las variables de un objeto con la proteccin de sus mtodos. Es guardar atributos y funcionalidades de una clase. No se puede acceder a los datos desde fuera de la clase teniendo acceso a ello solo los mtodos que se encuentren dentro de la clase, dividindola en interfaces e implementacin

4/12/12

Herencia
La

herencia es la capacidad que tiene una clase de derivar las propiedades y mtodos de otra, adoptando sus atributos y mtodos de la clase padre o primaria. Pero adems pueden introducir caractersticas particulares propias que las diferencian.

4/12/12

Polimorfismo
Clases

diferentes que tienen mtodos o atributos denominados de forma idntica, pero que se comportan de manera distinta, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizar el comportamiento correspondiente al objeto que se est usando

4/12/12

Base Abstracta
Utilizado

para conservar o mantener una cierta caracterstica o interfaz en comn. Representan los escalones ms elevados de algunas jerarquas de clases y solo sirven para derivar otras clases, en las que se van implementando detalles y concreciones

4/12/12

Metaclase y Subclase
MetaClase - Es una clase cuyas instancias son clases. - En otras palabras, como los objetos son instancias de una clase, las clases son instancias de una meta clase.
1.

4/12/12

Metaclase y Subclase
2. Subclase - Una subclase hereda ciertas caractersticas de las clases padres (e incluso pueden redefinirse o agregarse nuevas caractersticas de la clase superior tambin)

4/12/12

Estructura de Objeto
Asociacin

entre Objetos:

1. Generalizacin 2. Agregacin 3. Composicin

4/12/12

Generalizacin
Permite

una estructuracin jerrquica de las clases que comparten estructuras o comportamientos Consiste en crear clases genricas llamadas sper clases o clases padre, con los elementos comunes a un conjunto de subclases. Las subclases heredan (recogen) los atributos y comportamiento de la clase padre pudiendo agregar atributos y comportamiento propios, y modificar los atributos y comportamiento que vienen del padre.
4/12/12

Agregacin
La

agregacin es un tipo especial de relacin en el que se modela una semntica del tipo tiene o es parte de, en la que una entidad represente una entidad de mayor tamao (el todo), compuesta de entidades ms pequeas (las partes)

4/12/12

Composicin
La

agregacin es enteramente conceptual y lo nico que hace es distinguir un todo de una parte La composicin representa una pertenencia fuerte y una existencia coincidente entre el todo y la parte

4/12/12

Comportamiento de Objetos

1. Estados de un objeto 2. Eventos, tipos de eventos 3. Operaciones

4/12/12

Estados de un objeto
Se

refiere al conjunto de los valores de sus atributos en un instante de tiempo dado, la apariencia que el objeto presenta al usuario, y depende del valor que tenga sus propiedades. Los objetos interactan unos con otros y como consecuencia de esas interacciones cambian de estado.

4/12/12

Eventos
Los

eventos producen cambios en el estado de un objeto. Los eventos sirven como indicadores de los instantes en que ocurren los cambios de estado. Todos los objetos se relacionan con el mundo que los rodea, esto significa que ningn objeto est aislado y siempre recibe el influjo de otros objetos. Los eventos son los estmulos que un objeto ejerce sobre otro Los tipos de eventos indican los cambios sencillos en el estado de un objeto
4/12/12

Operaciones
Definen

el comportamiento de un objeto. Las operaciones definen el comportamiento de un objeto y cambian, de alguna manera, los atributos de dicho objeto. 1. Operaciones de manipulacin 2. Operaciones de estado 3. Operaciones que monitorizan

4/12/12

ANLISIS DEL SISTEMA

El objetivo del anlisis orientado a objetos es desarrollar una serie de modelos que describan el software de computadora al trabajar para satisfacer un conjunto de requisitos definidos por el cliente. Es un mtodo de anlisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema [booch 94]. El diseo Orientado a Objetos (DOO) difiere considerablemente del diseo estructurado ya que en DOO no se realiza un problema en trminos de tareas (subrutinas) ni en trminos de datos, sino se analiza el problema como un sistema de objetos que interactan 4/12/12

ANLISIS DEL DOMINIO

El anlisis del dominio del software es la identificacin, anlisis y especificacin de requisitos comunes de un dominio de aplicacin especfico, normalmente para su reutilizacin en mltiples proyectos dentro del mismo dominio de aplicacin.

Pressman ing. Software 4/12/12 quinta edicin

COMPONENTES DE ANALISIS
Los componentes estticos son estructurales por naturaleza, e indican caractersticas que se mantienen durante toda la vida operativa de una aplicacin. Los componentes dinmicos se centran en el control, y son sensibles al tiempo y al tratamiento de sucesos.

4/12/12

COMPORTAMIENTO DE OBJETOS
1.

2.

3.

4.

5.

La inteligencia del sistema debe distribuirse de manera igualitaria. Cada responsabilidad debe establecerse lo ms general posible. La informacin y el comportamiento asociado a ella, debe encontrarse dentro de la misma clase. La informacin sobre un elemento debe estar localizada dentro de una clase, no distribuida a travs de varias clases. Compartir responsabilidades entre clases relacionadas cuando sea apropiado.

4/12/12

DISEO DE SISTEMAS

Diseo orientado a objetos es una fase de la metodologa orientada a objetos para el desarrollo de Software. Su uso induce a los programadores a pensar en trminos de objetos, en vez de procedimientos, cuando planifican su cdigo El diseo orientado a objetos transforma el modelo de anlisis creado usando anlisis orientado a objetos , en un modelo de diseo que sirve como anteproyecto para la construccin de software teniendo el uso de capaz.

1.Diseo de responsabilidades 2.Diseo de mensajes 3.Diseo de clases y objetos 4.Diseo de subsistemas

4/12/12

DISEO DE SISTEMAS

La capa de responsabilidades.- Estructuras de datos y el diseo algortmico para todo los atributos y operaciones. La capa del subsistema.- representacin de los subsistemas que le permiten al software (requisitos e infraestructura tcnica que lo soportara) La capa de clases y Objetos.- jerarquas de clase que permiten crear el sistema usando generalizaciones y especializaciones mejor definidas. La capa de mensajes.- detalles que le permiten a cada objeto comunicarse con sus colaboradores. Esta capa establece las interfaces externas e internas para el sistema.

4/12/12

TRANSFORMACION

4/12/12

PROCESOS DEL DISEO DE SISTEMA

Se siguen los siguientes pasos: Particin del modelo de anlisis en subsistemas. Identificar la concurrencia dictada por el problema. Asignar subsistemas a procesadores y tareas. Desarrollar un diseo para la interfaz de usuario. Elegir una estrategia bsica para implementar la administracin (gestin) de datos. Identificar recursos globales y los mecanismos de control requeridos para su acceso. Disear un mecanismo de control apropiado para el sistema, incluyendo administracin de tareas. Considerar cmo deben manejarse las condiciones de frontera.
4/12/12

PROCESOS DEL DISEO DE OBJETOS

El diseo de objetos tiene que ver con el diseo detallado de los objetos y sus interacciones. Se completa dentro de la arquitectura global, definida durante el diseo del sistema y de acuerdo con las reglas y protocolos de diseo aceptados.

4/12/12