Boulevard Emilio Portes Gil #1301 Pte. A.P. 175 C.P. 87010 Cd. Victoria, Tamaulipas. http://www.itvictoria.edu.

mx/ EDUCACIN A D I S T A N C I A: U N I D A D ABASOLO

INGENIERIA
NOMBRE DE LA MATERIA:

Fundamentos de Ingeniera Software

NOMBRE DEL DOCUMENTO:

Actividad 1
NOMBRE DEL ASESOR:

ING. Hctor Manuel Villasana

ALUMNO:

Julio C. Resndiz R.
FECHA:

CONTROL: 11380876

26 de Noviembre del 2013

Modelo orientado a objetos Es la construccin de modelos de un sistema por medio de la identificacin y especificacin de un conjunto de objetos relacionados, que se comportan y colaboran entre s de acuerdo a los requerimientos establecidos para el sistema de objetos.

La metodologa de desarrollo de software orientada a objetos es cada da ms usada, pues permite desarrollar software fcilmente extensible y reusable. Esto ltimo es slo posible si los desarrolladores conocen muy bien los fundamentos que estn basados esta metodologa. Por eso, revisaremos los conceptos ms importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.

Es importante conocer la base del diseo y programacin de buenas clases, tanto por si solas como a travs del uso de herencia.

As como el concepto de subtipos, como concepto terico que est detrs de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Ms tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseo, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, proveer mecanismos para verificar si una clase y las relaciones entre ellas estn bien diseadas, y en particular si la herencia est bien usada.

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. El AOO, como los mtodos de anlisis convencionales descritos, forma un modelo de anlisis multiparte para satisfacer este objetivo.

El anlisis orientado a objetos aplica objeto-modelar tcnicas para analizar los requisitos funcionales para un sistema. El sistema orientado al objeto elabora los modelos del anlisis para producir especificaciones para la puesta en prctica. El Anlisis y el Diseo de sistema, tienen como fin estudiar sistemticamente la operacin de ingreso de los datos, el flujo de los mismos y la salida de la informacin; todo ello dentro del contexto de una empresa en particular.

IDENTIFICACIN DE CLASES Los diagramas de clases de UML se utilizan para documentar la estructura esttica del sistema; esto es, qu clases hay y cmo estn relacionadas. La tcnica del diagrama de clase se ha vuelto medular en los mtodos orientados a objetos. El diagrama de clase describe los tipos de objetos que hay en el sistema y las diversas clases de relaciones estticas que existen entre ellos.

Clases. Una clase describe un conjunto con un rol o roles equivalentes en un sistema. Los objetos y subdivisin en clases a menudo derivan de una de las siguientes fuentes: Cosas tangibles o del mundo real: libro, copia, curso. Roles: socio, estudiante, director de estudios. Eventos: llegada, salida, peticin. Interacciones: encuentro, interseccin.

Es importante recordar que los objetos son realmente cosas dentro de un programa de Computador; que cuando se habla sobre libros y copias.

La representacin de estas cosas dentro de nuestro sistema. Las consecuencias de esto son que hay que tener cuidado:

 De no almacenar informacin que es definitivamente irrelevante para nuestro sistema. De no perder la visin del hecho de que los objetos son el sistema!

El ltimo punto es particularmente interesante. Un error clsico es inventarse una clase, a menudo llamada [Cualquier cosa] System, que implementa todo el comportamiento interesante del sistema.

IDENTIFICACIN DE OBJETOS Y CLASES.

La construccin de un modelo de clases incluye la identificacin de las clases que deberan existir en nuestro sistema: sta es una parte fundamental del trabajo de disear un sistema orientado a objetos. Hay dos objetivos que se pretenden alcanzar: Construir, lo ms rpido y barato posible, un sistema que satisfaga nuestros requisitos actuales. Para ello: Cada comportamiento que requiera el sistema debe ser proporcionado por los objetos de las clases que elijamos. Construir un sistema que sea fcil de mantener y adaptar a futuros requisitos. Para Lograrlo: Un buen modelo de clases est formado por mdulos encapsulados, con Acoplamiento y cohesin fuerte.

En la prctica, es probable que al construir un modelo de clases lo haga correctamente la primera vez. La coleccin de clases en su modelo de diseo, es una de las cosas que probablemente cambiar a los largo y dentro de las iteraciones de desarrollo.

MODELO DE ESTRUCTURA DE OBJETOS El modelo de estructura de Objetos (OSM) es el modelo central. Contiene las clases de objetos requeridas para construir la aplicacin y las relaciones entre ellas. Se construye a travs de un proceso aditivo durante todo el ciclo de desarrollo del sistema. MODELO DE SECUENCIAS DE TRANSACCIONES El modelo de procesos de negocios (BPM) describe los procesos que se llevan a cabo en la organizacin. Se lo utiliza para analizar la organizacin y comprender sus procesos, parte de los cuales (o todos), sern soportados por el sistema a desarrollar. El modelo de secuencia de transacciones (TSM) parte de la especificacin de alto nivel del BPM y lo traslada en requerimientos para la aplicacin. El TSM se corresponde conceptualmente con lo USE-CASEs de Jacobson (OOSE). DIAGRAMAS DE INTERACCIN DE OBJETOS Los diagramas de interaccin de objetos muestran las interacciones entre objetos requeridas para proveer al usuario los servicios descriptos en el TSM. DIAGRAMAS DE FLUJO DE ACTIVIDAD Los diagramas de flujo de actividad son utilizados para analizar y presentar flujos de actividad complejos en los procesos de negocio y en las secuencias de transacciones (secuencias, iteraciones, y decisiones). MODELO DE CICLO DE VIDA DE OBJETOS El modelo de ciclo de vida de objetos es utilizado para describir como un objeto cambia de estados en el tiempo y que eventos producen dichos cambios de estado.

MODELO GLOBAL DEL SISTEMA El modelo global del sistema es utilizado para dividir el sistema en unidades de diseo manejables. Es una herramienta para manejar la complejidad de desarrollo de grandes sistemas. Especifica la interfaces entre las unidades de diseo. MODELO DE ESTRUCTURA DE OBJETOS (OSM) Conceptos y propsito del modelo de estructura de objetos El OSM es el modelo fundamental que provee un medio uniforme para modelar el sistema desde la captura de requerimientos en la etapa inicial del anlisis hasta la implementacin, atravesando todo el ciclo de desarrollo del sistema. Este modelo identifica: Las clases de objetos en la aplicacin Como las clases de objetos se asocian unas con otras Como se comunican los objetos Los detalles de cada clase de objetos, incluyendo atributos y operaciones Durante el proceso de anlisis y diseo, el OSM es definido en sucesivos niveles incrementales de detalle, hasta que el nivel necesario para la implementacin es alcanzado. Todos los dems modelos capturan detalles que alimentan es modelo. El desarrollo de OSM es un proceso aditivo, diferencindose esto del enfoque transformacional caracterstico de otros mtodos como el estructurado, donde los DFD del anlisis son transformados en diagramas de estructura durante el diseo, con los consiguientes problemas que esto acarrea. Durante el ciclo de desarrollo se aportan los siguientes elementos al modelo: Anlisis del Negocio: se reconocen objetos claves del negocio y generan las abstracciones en las clases apropiadas (objetos entidad).

Anlisis de Requerimientos: se identifican asociaciones estructurales entre objetos y nuevas clases (entidad). Diseo lgico: Se incorporan todas las clases necesarias para la aplicacin incluyendo los objetos de interfaz y de control. Diseo Fsico: se incorporan todos los detalles remanentes para la

implementacin fsica de cada clase de objetos. Componentes del modelo de estructura de objetos. El componente bsico del OSM es la clase de objetos. Se distinguen tres tipos de clases: Objetos Entidad Objetos de Interfaz Objetos de Control. Para cada clase identificada se describen: Operaciones Atributos Restricciones Adicionalmente el OSM describe las asociaciones entre objetos o clases de objetos. Se distinguen los siguientes tipos de asociaciones: Relaciones Estticas Herencia Agregacin Comunicacin por mensajes

OBJETOS ENTIDAD Representan algo real o abstracto sobre el cual el sistema necesita almacenar datos. Representan la memoria esencial del negocio. Los objetos del negocio (business objects) son normalmente objetos entidad. Ejemplos de objetos entidad pueden ser empleados, alumno, etc. Se representan en el diagrama de estructura de objetos con el siguiente smbolo: OBJETOS INTERFACE Representan los objetos tcnicos requeridos para vincular la aplicacin con el entorno. Representan el vnculo a travs del cual el sistema recibe o suministra datos e informacin al entorno. Tpicamente incluyen interfaces con el usuario (pantallas, reportes, etc.) e interfaces con otras aplicaciones. Se representan en el diagrama de estructura de objetos con el siguiente smbolo: OBJETOS DE CONTROL Contienen comportamiento que no pertenece naturalmente ni a objetos entidad ni de interfaz. Son normalmente objetos transitorios, como ser un controlador de reportes. Se representan en el diagrama de estructura de objetos con el siguiente smbolo: CLASES ABSTRACTAS Y CONCRETAS Una clase de la cual pueden generarse instancias particulares (objetos), se denomina clase concreta. Una clase abstracta es aquella que no instancias (objetos) propias. Las clases abstractas son un poderoso mecanismo conceptual para definir estructuras comunes de atributos, operaciones, y restricciones, reutilizadas a travs de la herencia por mltiples clases concretas.

OPERACIONES Una operacin define un servicio ofrecido por un objeto junto con la informacin que debe suministrarse cuando es invocado (nombre, argumentos de

entrada/salida). Tambin puede contener una especificacin de mtodo, el cual especifica una implementacin para la operacin. Algunas operaciones pueden asumirse que existen para cada clase de objetos sin identificarlas formalmente. Estas son llamadas operaciones implcitas. Las operaciones implcitas ms importantes son Crear, Destruir, Leer, y Actualizar. Una operacin implcita debe ser formalmente definida cuando sus pre y post condiciones no sean triviales. ATRIBUTOS Son valores de datos asociados a los objetos de una clase al cual describen. Estn fuertemente asociados con la clase de objetos que los contienen, de tal forma que no tienen existencia independiente o identidad de objeto. Cada atributo identificado debe ser atmico en el sentido de que debe ser tratado como una unidad. En tal caso puede ser un valor simple o grupo de valores tratados siempre como unidad (ej. direccin). Debe notarse que las clases no se modelan en formas normales. La decisin sobre la estructura de datos subyacente a utilizar se difiere hasta el Diseo Fsico. Los atributos pueden basarse en definiciones de tipos de atributos, lo cual provee una definicin estndar sobre formato, longitud y dominio de valores para atributos del mismo tipo.

RESTRICCIONES Las restricciones pueden especificarse sobre los valores que

un atributo o relacin pueden tomar. La implementacin de las restricciones puede realizarse de diferentes formas: Reglas de validacin durante los procesos de entrada de datos (user inputs) Database-level triggers Lgica de control contenida en una o ms operaciones. RELACIONES ESTTICAS Las relaciones estticas describen como los objetos se asocian unos con otros en la misma forma que en el modelo entidad-relacin. Identifican as

mismo dependencias entre objetos, cuando un objeto requiere de la existencia de otro ya sea de la misma clase o de otra. Las relaciones estticas se establecen usualmente entre objetos de tipo Entidad. Al igual que los atributos, las relaciones modelan informacin sobre un objeto (cosas que un objeto debe conocer sobre s mismo). Estas son propiedades de un objeto. Los atributos son valores de datos. Las relaciones son valores que referencian otros objetos. Una relacin esttica se representa en el diagrama de estructura de objetos como una lnea slida entre las clases de objetos, con smbolos de cardinalidad en sus extremos. Las relaciones pueden etiquetarse para identificar el propsito de la asociacin. El diseador puede optar por: un nombre para cada direccin de la relacin un nombre para una direccin de la relacin un solo nombre que representa ambas direcciones de la relacin sin nombre

Por cuestiones de simplicidad, las relaciones son modeladas como binarias, es decir, solo dos clases de objetos, no necesariamente distintas, participan en la relacin. Es posible que entre el mismo par de clases exista ms de una relacin. La cardinalidad identifica el nmero mximo y mnimo de instancias de una clase (objetos) que participan en una relacin dada, en el mismo sentido que lo hacen en el modelo entidad-relacin.

REFERENCIAS: http://www.taringa.net/posts/apuntes-y-monografias/9501222/Modelo-orientado-aobjetos.html http://es.scribd.com/doc/54060993/05-Identificacion-de-clases http://html.rincondelvago.com/modelado-y-diseno-orientado-a-objetos.html