Unidad III Paradigm As de La Ingenieria de Software

22
 UNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE Introducción: a los Paradigmas de la Ingeniería del Software La ingeniería de Software surge de la ingeniería de Sistemas y de Hardware. Abarca un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo de Software y suministran las bases para construir Software de calidad de una forma productiva: • Métodos • Herramientas • Procedimientos Métodos que indican cómo construir el Software técnicamente e incluyen un amplio espectro de métodos para la planificación, la estimación, el análisis, el diseño, codificación, prueba y mantenimiento. Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. Cuando se integran las herramientas de forma que la información creada por una herramienta puede ser usada por otra, se establece un Sistema para el soporte del desarrollo de Software, llamado Ingeniería de Software Asistida por Computadora (CASE). Procedimientos que definen la secuencia en la que se aplican los métodos, las entregas, los controles de calidad y guías para evaluación del progreso. La Ingeniería de Software está compuesta por una serie de pasos que abarcan los métodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniería de Software. a) Los que soportan técnicas de programación de bajo nivel (copia de ficheros frente estructuras de datos compartidos) b) Los que soportan métodos de diseño de algoritmos (programación dinámica) c) Los que soportan soluciones de programación de alto nivel. La ingeniería de Software está compuesta por una serie de pasos de abarcan los métodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniería de Software. La elección de un paradigma para la ingeniería de Software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos. 3.1 En el Enfoque E structurado Se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al Sistema antes de plasmarlo a código fuente. DFD es un diagrama en el q participan procesos (métodos), flujo de datos (argumentos) y archivos (base de datos). Hay de diferentes niveles dependiendo la complejidad del Sistema que analiza. Hablando de lenguajes Tiene muchas diferencias con la OO. Un mínimo cambio en el código puede llegar alterar al resto del programa cosa que en uno OO bien encarado eso no sucede lo cual es una ventaja porque así no se pierde

Transcript of Unidad III Paradigm As de La Ingenieria de Software

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 1/22

 

UNIDAD III PARADIGMAS DE LA INGENIERIA DE SOFTWARE

Introducción: a los Paradigmas de la Ingeniería del Software

La ingeniería de Software surge de la ingeniería de Sistemas y de Hardware.

Abarca un conjunto de tres elementos que facilitan el control sobre el proceso dedesarrollo de Software y suministran las bases para construir Software de calidadde una forma productiva:

• Métodos • Herramientas • Procedimientos 

Métodos que indican cómo construir el Software técnicamente e incluyen unamplio espectro de métodos para la planificación, la estimación, el análisis, eldiseño, codificación, prueba y mantenimiento.Herramientas automáticas y semiautomáticas que apoyan a la aplicación de losmétodos. Cuando se integran las herramientas de forma que la información creadapor una herramienta puede ser usada por otra, se establece un Sistema para elsoporte del desarrollo de Software, llamado Ingeniería de Software Asistida porComputadora (CASE).Procedimientos que definen la secuencia en la que se aplican los métodos, lasentregas, los controles de calidad y guías para evaluación del progreso.La Ingeniería de Software está compuesta por una serie de pasos que abarcan losmétodos, herramientas y procedimientos mencionados, a los que se denominanParadigmas de la Ingeniería de Software.a) Los que soportan técnicas de programación de bajo nivel (copia de ficherosfrente estructuras de datos compartidos)b) Los que soportan métodos de diseño de algoritmos (programación dinámica)c) Los que soportan soluciones de programación de alto nivel.La ingeniería de Software está compuesta por una serie de pasos de abarcan losmétodos, las herramientas y los procedimientos antes mencionados.Estos pasos se denominan frecuentemente paradigmas de la ingeniería deSoftware.La elección de un paradigma para la ingeniería de Software se lleva a cabo deacuerdo con la naturaleza del proyecto y de la aplicación, los métodos,herramientas a usar, los controles y entregas requeridos.

3.1 En el Enfoque Estructurado

Se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta paraentender al Sistema antes de plasmarlo a código fuente. DFD es un diagrama enel q participan procesos (métodos), flujo de datos (argumentos) y archivos (basede datos). Hay de diferentes niveles dependiendo la complejidad del Sistema queanaliza. Hablando de lenguajes Tiene muchas diferencias con la OO. Un mínimocambio en el código puede llegar alterar al resto del programa cosa que en unoOO bien encarado eso no sucede lo cual es una ventaja porque así no se pierde

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 2/22

 

tiempo en arreglar cosas ya hechas. Otra desventaja es que una porción decódigo en lenguaje estructurado es difícil que pueda servir en otros proyectos, estosí es habitual en lenguajes OO, con solo importar clases ya hechas se escribemenos código y se ahorra tiempo.

3.1.1 Diagramas de Flujo de DatosUn diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representarel funcionamiento de un Sistema en un proyecto Software. Sus elementos gráficosson círculos, flechas, y rectángulos cerrados o abiertos. Los cerrados representanentidades externas mientras que los abiertos describen almacenes o archivos. Loscírculos significan procesos y las flechas flujos de datos desde, o hacia, unproceso.En un DFD también se utiliza la escritura. Los flujos, entidades externas y losalmacenes se etiquetan con un nombre. Los procesos se etiquetan con un númeroy un verbo en infinitivo con objeto directo.

Un diagrama de flujo de datos puede ser profundizado expandiendo algunos desus procesos en subprocesos, en este caso la etiqueta tendrá un númeroadicional. No hay un límite para el número de procesos.Un diagrama de flujo de datos (DFD por sus siglas en español e inglés) es unarepresentació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 deprocesamiento de datos (diseño estructurado). Es una práctica común para undiseñador dibujar un contexto a nivel de DFD que primero muestra la interacciónentre el Sistema y las entidades externas. Este contexto a nivel de DFD se“explotó” para mostrar más detalles del Sistema que se está modelando.Los diagramas de flujo de datos fueron inventados por Larry Constantine, el

desarrollador original del diseño estructurado, basado en el modelo decomputación de Martin y Estrin: “flujo gráfico de datos”. Los diagramas de flujo dedatos (DFDs) son una de las tres perspectivas esenciales de Análisis de SistemasEstructurados y Diseño por Método SSADM. El patrocinador de un proyecto y losusuarios finales tendrán que ser informados y consultados en todas las etapas deuna evolución del Sistema. Con un diagrama de flujo de datos, los usuarios van apoder 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 flujode datos puede ser elaborado y se comparó con el nuevo Sistema de diagramasde flujo para establecer diferencias y mejoras a aplicar para desarrollar un Sistemamás eficiente. Los diagramas de flujo de datos pueden ser usados paraproporcionar al usuario final una idea física de cómo resultarán los datos a últimainstancia, y cómo tienen un efecto sobre la estructura de todo el Sistema. Lamanera en que cualquier Sistema es desarrollado puede determinarse a través deun diagrama de flujo de datos. El desarrollo de un DFD ayuda en la identificaciónde los datos de la transacción en el modelo de datos.

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 3/22

 

Los diagramas derivados de los procesos principales se clasifican en niveles, loscuales son:Nivel 0: Diagrama de contexto.Nivel 1: Diagrama de nivel superior.Nivel 2: Diagrama de detalle o expansión.

3.1.2 Diccionario de datos

El diccionario de datos es un listado organizado de todos los datos que pertenecena un Sistema.El objetivo de un diccionario de datos es dar precisión sobre los datos que semanejan en un Sistema, evitando así malas interpretaciones o ambigüedades.Define con precisión los datos de entrada, salida, componentes de almacenes,flujos, detalles de las relaciones entre almacenes, etc.Los diccionarios de datos son buenos complementos a los diagramas de flujo dedatos, los diagramas de entidad-relación, etc.

Un diccionario de datos es un conjunto de metadatos que contiene lascaracterísticas lógicas de los datos que se van a utilizar en el Sistema que seprograma, incluyendo nombre, descripción, alias, contenido y organización.Estos diccionarios se desarrollan durante el análisis de flujo de datos y ayuda a losanalistas que participan en la determinación de los requerimientos del Sistema, sucontenido también se emplea durante el diseño del proyecto.Identifica los procesos donde se emplean los datos y los sitios donde se necesitael acceso inmediato a la información, se desarrolla durante el análisis de flujo dedatos y auxilia a los analistas que participan en la determinación de losrequerimientos 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 más importantesson flujos de datos, almacenes de datos y procesos. El diccionario de datosguarda los detalles y descripción de todos estos elementos.NOTACIÓNLas estructuras de datos son descritas por lo general usando notación algebraica.La notación algebraica usa los siguientes símbolos:

1. Un signo de igual (=) significa “está compuesto de”. 

2. Un signo de más (+) significa “y”. 3. Las llaves { } indican elementos repetidos, también llamados grupos repetidos otablas. Puede haber uno o varios elementos repetidos dentro del grupo. El gruporepetido puede tener condiciones, tales como una cantidad fija de repeticiones olímites, superior e inferior para la cantidad de repeticiones.4. Los corchetes [ ] representan una situación disyuntiva. Puede estar presente unelemento u otro, pero no ambos. Los elementos listados entre corchetes sonmutuamente excluyentes, y se separan mediante barras ( | ).

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 4/22

 

5. Los paréntesis ( ) representan un elemento opcional. Los elementos opcionalespueden ser dejados en blanco en las pantallas de captura, y pueden contenerespacios o ceros para los campos numéricos en las estructuras de archivo.6. La “@” (o una definición subrayada) identifica la llave para un almacén de datos.7. Una frase entre asteriscos es un comentario (* *).

EJEMPLO:Nombre = Título + Primer-nombre + Apellido-paterno + Apellido-maternoTítulo = [ Sr | Sra | Dr | Ing]Primer-nombre = {caracter}Apellido-paterno = {caracter}Apellido-materno = {caracter}caracter = [A-Z|a-z| |’] a 

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”. Paradefinir un dato completamente, la definición debe incluir: • El significado del datoen el contexto de la aplicación. Esto se documenta en forma de comentario. • Lacomposició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 nopuede ser descompuesto.

DATOS ELEMENTALESSon aquellos para los cuales no hay una descomposición significativa. Porejemplo, puede ser que no se requiera descomponer el nombre de una persona enprimer-nombre, apellido-materno y apellido-paterno; esto depende del contexto del

Sistema que se esté modelando. Cuando se han identificado los datoselementales, deben ser introducidos en el DD y proveer una breve descripción quedescriba el significado del dato. En el caso de que el dato tenga un nombresignificativo, se puede omitir la descripción, sin embargo, es importante especificarlas 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íade Software I Análisis Estructurado 24

DATOS OPCIONALES

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

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 5/22

 

SELECCIÓN

Indica que un elemento consiste de exactamente una opción de un conjunto dealternativas. 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 elementocompuesto. Ejemplo: Orden de compra = nombre-cliente + dirección-de-envío +{artículo} significa que una orden de compra siempre debe contener un nombre decliente, 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 significaque una orden de compra siempre debe contener un nombre de cliente, unadirección de envío y de 1 a 10 artículos. APGR Ingeniería de SoftwareI Análisis Estructurado 25 Ejemplos de iteraciones con límites: a = 1{b} a = {b} 10 a= 1{b}10 a = {b}

3.1.3 Diseño de Módulos.

Un modelo de datos es un lenguaje orientado a describir una Base de Datos.Típicamente un Modelo de Datos permite describir:

• Las estructuras de datos de la base: El tipo de los datos que hay en la base y laforma en que se relacionan.• Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.• Operaciones de manipulación de los datos: típicamente, operaciones deagregado, borrado, modificación y recuperación de los datos de la base.Otro enfoque es pensar que un modelo de datos permite describir los elementosde la realidad que intervienen en un problema dado y la forma en que serelacionan esos elementos entre sí.No hay que perder de vista que una Base de Datos siempre está orientada aresolver un problema determinado, por lo que los dos enfoques propuestos sonnecesarios en cualquier desarrollo de Software.Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlode acuerdo al nivel de abstracción que presentan: Modelos de DatosConceptualesSon los orientados a la descripción de estructuras de datos y restricciones deintegridad. Se usan fundamentalmente durante la etapa de Análisis de unproblema dado y están orientados a representar los elementos que intervienen enese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 6/22

 

Modelos de Datos Lógicos

Son orientados a las operaciones más que a la descripción de una realidad.Usualmente están implementados en algún Manejador de Base de Datos. Elejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de

contar también con buenas características conceptuales (Normalización de basesde datos).

Modelos de Datos Físicos

Son estructuras de datos a bajo nivel implementadas dentro del propio manejador.Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash,etc.Un (DFD) presenta ser subdividido en diferentes partes, que llamaremos módulosconteniendo cada uno de ellos procedimientos manuales o automatizados, a fin deque el Sistema pueda ser desarrollado y ejecutado en unidades menores, más

fáciles de implementar manejar y controlar.Estos módulos pueden ser un programa, un procedimiento, una relación deoperaciones o comandos

3.1.4 Descomposición En Procesos.

Las organizaciones, funcionales, desarrollan múltiples actividades el componentebásico de estas corresponde a la tarea, entendida como una microactividad que seresponsabiliza a una sola persona.Grupos de tareas conforman actividades más complejas que se denominanprocesos.Todos los procesos tienen entradas (recursos humanos, tecnológicos materiales,etc.) para el desarrollo de las actividades que lo conforman; como salidas seesperan productos, servicios, información, activos financieros, etc.Entiende todo proceso como un: “CONJUNTO DE TAREAS LOGICAMENTERELACIONADAS QUEEXISTEN PARA OBTENER UN RESULTADO BIEN DEFINIDO DENTRO DE UNNEGOCIO”. 

3.2 Enfoque Orientado a Objetos.

Historia:

Vivimos en un mundo de objetos. Estos objetos existen en la naturaleza, enentidades hechas por el hombre, en los negocios y en los productos que usamos.Pueden ser clasificados, descritos, organizados, combinados, manipulados ycreados. Por eso no es sorprendente que se proponga una visión orientada aobjetos para la creación de Software de computadora, una abstracción quemodela el mundo de forma tal que nos ayuda a entenderlo y gobernarlo mejor.

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 7/22

 

La primera vez que se propuso un enfoque orientado a objetos para el desarrollode Software fue a finales de los años sesenta. Sin embargo, las tecnologías deobjetos han necesitado casi veinte años para llegar a ser ampliamente usadas.Durante los años 90, la ingeniería del Software orientada a objetos se convirtió enel paradigma de elección para muchos productores de Software y para un

creciente número de Sistemas de información y profesionales de la ingeniería.Las tecnologías de objetos llevan a reutilizar, y la reutilización (de componente deSoftware) lleva a un desarrollo de Software más rápido y a programas de mejorcalidad. El Software orientado a objetos es más fácil de mantener debido a que suestructura es inherentemente poco acoplada. Esto lleva a menores efectoscolaterales cuando se deben hacer cambios. Los Sistemas orientados a objetosson más fáciles de adaptar y más fácilmente escalables (pueden crearse grandesSistemas ensamblando subsistemas reutilizables).Hacia mediados de los 80, los beneficios de la programación orientada a objetosempezaron a obtener reconocimiento, y el diseño de objetos pareció ser unenfoque sensato para la gente que deseaba utilizar el lenguaje de programación

orientada a objetos. Un enfoque orientado a objetos para programar ofrecemuchos beneficios sobre un enfoque estructurado.El análisis orientado a objetos y su diseño se enfoca en los objetos. Los objetostienen ciertos comportamientos y atributos que determinan la manera en queinteractúan y funcionan. No se intenta proporcionar un orden para las acciones almomento del diseño debido a que los objetos funcionan basados en la manera enque funcionan otros objetos. La programación orientada a objetos ayuda a losdesarrolladores a crear objetos que reflejan escenarios del mundo real.Las implementaciones orientadas a objetos ocultan datos, lo cual significa quemuestran únicamente los comportamientos a los usuarios y ocultan el códigosubyacente de un objeto. Los comportamientos que el programador expone son

únicamente aquellos elementos que el usuario de un objeto puede afectar.El enfoque orientado a objetos permite que los objetos estén autocontenidos. Losobjetos existen por sí mismos, con una funcionalidad para invocarcomportamientos de otros objetos. Al utilizar un enfoque orientado a objetos, losdesarrolladores pueden crear aplicaciones que reflejan objetos del mundo real,como rectángulos, elipses y triángulos, además de dinero, números de partes yelementos en un inventario.En un enfoque orientado a objetos, los objetos, por definición, son modulares ensu construcción. Esto quiere decir que son entidades completas y, por lo tanto,tienden a ser altamente reutilizables. Las aplicaciones orientadas a objetos seconstruyen sobre el paradigma de los mensajes o de los eventos en donde losobjetos envían mensajes a otros objetos, como el Sistema operativo Microsoft® Windows®.

a. El paradigma orientado a objetos

Durante muchos años el término Orientado a Objetos (OO) se usó para referirse aun enfoque de desarrollo de Software que usaba uno de los lenguajes orientadosa objetos (Ada 95, C++, Eiffel, Smalltalk, etc.). En el libro The Structure ofScientific Revolutions, el historiador Thomas K describía un paradigma como un

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 8/22

 

conjunto de teorías, estándar y métodos que juntos representan un medio deorganización del conocimiento: es decir, un medio de visualizar el mundo. En estesentido, la programación orientada a objetos es un nuevo paradigma. Laorientación a objetos fuerza a reconsiderar nuestro pensamiento sobre lacomputación, sobre lo que significa realizar computación y sobre cómo se

estructura la información dentro de la computadora.Jenkins y Glasgow observan que “la mayoría de los programadores trabajan en unlenguaje y utilizan sólo un estilo de programación. Ellos programan en unparadigma forzado por el lenguaje que utilizan. Con frecuencia, no se enfrentan amétodos alternativos de resolución de un problema, y por consiguiente tienendificultad en ver la ventaja de elegir un estilo más apropiado al problema amanejar”. Bobrow y Stefik sugieren que existen cuatro clases de estilos deprogramación:

Orientados a procedimientos: Algoritmos.Orientados a objetos: Clases y Objetos.

Orientados a lógica: Expresado en cálculo de predicados.Orientados a reglas: Reglas if-then.

No existe ningún estilo de programación idóneo para todas las clases deprogramación. La orientación aobjetos se acopla a la simulación de situaciones del mundo real.b. Orientación a ObjetosLa orientación a objetos puede describirse como el conjunto de disciplinas quedesarrollan y modelanSoftware, que facilitan la construcción de Sistemas complejos a partir decomponentes.

El atractivo intuitivo de la orientación a objetos es que proporciona conceptos yherramientas con lascuales se modela y representa el mundo real tan fielmente como sea posible.Estos conceptos yherramientas orientados a objetos son tecnologías que permiten que losproblemas del mundo real seanexpresados de modo fácil y natural.Las técnicas orientadas a objetos proporcionan mejoras y metodologías paraconstruir Sistemas deSoftware complejos a partir de unidades de Software modularizado y reutilizable.Se necesita un nuevoenfoque para construir Software en la actualidad. Este nuevo enfoque debe sercapaz de manipular tantoSistemas grandes como pequeños y debe crear Sistemas fiables que seanflexibles, mantenibles y capacesde evolucionar para cumplir las necesidades del cambio.La orientación a objetos trata de cubrir las necesidades de los usuarios finales, asícomo las propias de losdesarrolladores de productos Software. Estas tareas se realizan mediante lamodelización del mundo real.

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 9/22

 

El soporte fundamental es el modelo objeto.Un objeto es la instancia de una clase. Una clase es la representación abstractade un concepto en elmundo real, y proporciona la base a partir de la cual creamos instancias de objetosespecíficos. Como

ejemplo, puede crear una clase que defina a un cliente. Después puede crear unanueva instancia de laclase cliente para tener un objeto utilizable de Cliente. Para poder crear un objetode la clase cliente, debecrear una nueva instancia basada en esa clase.Por ejemplo:Private Objeto Customer ? as Clase Customer ?Objeto Customer = New Clase Customer()

Cada objeto es un elemento único de la clase en la que se basa. Si una clase escomo un molde, entoncesun objeto es lo que se crea a partir del molde. La clase es la definición de unelemento; el objeto es elelemento. El molde para una figura de cerámica en particular, es como una clase;la figura es el objeto.Todos los objetos están compuestos de tres cosas:Interfaz:La Interfaz es el conjunto de métodos, propiedades, eventos y atributos que sedeclaran como públicos en

su alcance y que pueden invocar los programas escritos para usar nuestro objeto.Implementación:Al código dentro de los métodos se le llama Implementación. Algunas vecestambién se le llamacomportamiento, ya que este código es el que efectivamente logra que el objetohaga un trabajo útil. Esimportante entender que las aplicaciones del cliente pueden utilizar nuestro objetoaunque cambiemos laimplementación, siempre que no cambiemos la interfaz. Siempre que semantengan sin cambio nuestronombre de método, su lista de parámetro y el tipo de datos de devolución,

podremos cambiar laimplementación totalmente.Estado:El estado o los datos de un objeto es lo que lo hace diferente de otros objetos dela misma clase. El estadose describe a través de las variables del Miembro o de la Instancia. Las variablesdel miembro son aquellas

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 10/22

 

declaradas, de tal manera que están disponibles para todo el código dentro de laclase. Por lo general, lasvariables del miembro son Privadas en su alcance. Algunas veces, se les conocecomo variables de lainstancia o como atributos. Observe que las propiedades no son variables del

Miembro, ya que son un tipode método que funciona para recuperar y establecer valores.¿Qué es una clase?Una clase es esencialmente un proyecto, a partir del cual puede crear objetos.Una clase define lascaracterísticas de un objeto, incluyendo las propiedades que definen los tipos dedatos que ese objetopuede contener y los métodos que describen el comportamiento del objeto. Estascaracterísticasdeterminan la manera en que otros objetos pueden acceder y trabajar con losdatos que se incluyen en el

objeto.Para definir una clase, se coloca la palabra clave Class antes del nombre de suclase, y después se insertanlos miembros de la clase (datos y métodos) entre la definición del nombre de laclase y la instrucción EndClass. Si incluye los métodos, entonces el código de cada método también sedebe incluir entre ladeclaración del método y el final del mismo.Por ejemplo, si desea construir objetos que representen perros, puede definir unaclase Perro con ciertoscomportamientos, como caminar, ladrar y comer, y propiedades específicas, como

altura, peso y color.Una vez que haya definido la clase Perro, puede crear objetos con base en esaclase. Es importanteobservar que todos los objetos Perro creados con base en la clase perrocompartirán los mismoscomportamientos, pero tendrán sus propios valores específicos para el mismoconjunto de propiedades.El siguiente ejemplo representa la definición de la clase Perro. Tome enconsideración que ésta no es unasintaxis estricta de VB.NET; simplemente es un ejemplo de la definición de clase.Public Class Perro Dim Altura As Decimal Dim Peso As Decimal Dim Color As String Sub Caminar(ByVal Pasos As Integer) End Sub 

Sub Ladrar() 

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 11/22

 

End Sub Sub Comer() End Sub End Class #] 

Vamos con otro ejemplo. El siguiente ejemplo define una nueva clase, Persona,con dos partes deinformación relevante asociadas: el nombre de la persona, su fecha de nacimientoy un Método quecalcula la edad de la persona. A pesar de que la clase Persona se define en elejemplo, no existe aún elobjeto Persona. Deberán ser creados.[@ Public Class Persona Private mstrNombre As String Private mdtFechaNacimiento As Date 

Public Function Edad() As Integer Return DateDiff(DateInterval.Year, mdtFechaNacimiento, Now()) End Function End Class Una clase es un tipo definido por el usuario en contraposición a un tipoproporcionado por el Sistema. Aldefinir una clase, en realidad crea un nuevo tipo en su aplicación.Ahora que ya sabéis todo esto, vamos con os elementos (propiedades) másimportantes de este modelo.Estas son:Abstracción.

Encapsulamiento.Modularidad.Jerarquía.Polimorfismo.Como sugiere Booch, si alguno de estos elementos no existe se dice que elmodelo no es orientado aobjetos.Abstracción:La abstracción es uno de los medios más importantes, mediante el cual nosenfrentamos con lacomplejidad inherente al Software. La abstracción es la propiedad que permite

representar lascaracterísticas esenciales de un objeto, sin preocuparse de las restantescaracterísticas (no esenciales).Abstracción es la técnica de quitarle a una idea o a un objeto todos losacompañamientos innecesarioshasta que los deja en una forma esencial y mínima. Una buena abstracciónelimina todos los detalles pocoimportantes y le permite enfocarse y concentrarse en los detalles importantes.

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 12/22

 

Una abstracción se centra en la vista externa de un objeto, de modo que sirvapara separar elcomportamiento esencial de un objeto de su implementación. Definir unaabstracción significa describiruna entidad del mundo real, no importa lo compleja que pueda ser y, a

continuación, utilizar estadescripción en un programa.

El elemento clave de la programación orientada a objetos es la clase. Una clasese puede definir como unadescripción abstracta de un grupo de objetos, cada uno de los cuales se diferenciapor su estado específicoy por la posibilidad de realizar una serie de operaciones. Por ejemplo, una pluma

estilográfica es un objetoque tiene un estado (llena de tinta o vacía) y sobre la cual se pueden realizaralgunas operaciones (escribir,poner o quitar la tapa, llenar de tinta si está vacía, etc.).La idea de escribir programas definiendo una serie de abstracciones no es nueva,pero el uso de clases paragestionar dichas abstracciones en lenguajes de programación ha facilitadoconsiderablemente suaplicación.La abstracción es un principio de Software importante. Una clase bien diseñadaexpone un conjunto

mínimo de métodos cuidadosamente considerados que proporcionan elcomportamiento esencial de unaclase en una forma fácil de usar. Crear buenas abstracciones de Software no esfácil. Encontrar buenasabstracciones generalmente requiere de un entendimiento muy claro del problemay de su contexto, granclaridad de pensamiento y amplia experiencia.Existe un principio muy importante relacionado con la abstracción, y esta es, laDependencia mínima. Lasmejores abstracciones de Software hacen que las cosas complejas sean simples.Logran esto al ocultar por

completo los aspectos no esenciales de una clase. Estos aspectos no esenciales,una vez que han sidodebidamente ocultados, no se pueden ver, ni usar, ni depender de ellos. Esteprincipio de dependenciamínima es lo que hace que la abstracción sea tan importante. El cambio es normalen el desarrollo deSoftware. Lo mejor que puede hacer es minimizar el impacto de un cambio cuandoéste sucede. Y cuanto

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 13/22

 

menos dependa de algo, menos se verá afectado cuando cambie.Los lenguajes orientados a objetos proporcionan la Encapsulación. Laencapsulación se puede utilizar paraaplicar el concepto de Abstracción.Encapsulamiento

El Encapsulamiento o encapsulación es la propiedad que permite asegurar que elcontenido de lainformación de un objeto está oculta al mundo exterior: el objeto A no conoce loque hace el objeto B, yviceversa. La encapsulación (también se conoce como ocultación de lainformación), en esencia, es elproceso de ocultar todos los secretos de un objeto que no contribuyen a suscaracterísticas esenciales.La encapsulación permite la división de un programa en módulos. Estos módulosse implementanmediante clases, de forma que una clase representa la encapsulación de una

abstracción. En la práctica,esto significa que cada clase debe tener dos partes: una interfaz y unaimplementación. La interfaz de unaclase captura sólo su vista externa y la implementación contiene la representaciónde la abstracción, asícomo los mecanismos que realizan el comportamiento adecuado.Encapsulación es la capacidad de contener y controlar el acceso a un grupo deelementos asociados. Lasclases proporcionan una de las formas más comunes para encapsular elementos.En el siguiente ejemplo,la clase Bank Account? Encapsula los métodos, campos y propiedades que se

describen en una cuentabancaria. Sin una encapsulación, usted necesitaría declarar procedimientos yvariables por separado paraalmacenar y administrar información para la cuenta bancaria, y sería difícil trabajarcon más de una cuentabancaria a la vez. La encapsulación le permite utilizar los datos y procedimientosen la clase BankAccount como una unidad. Usted puede trabajar con varias cuentas bancarias almismo tiempo sinconfusión, debido a que cada cuenta está representada por una instancia única dela clase.La encapsulación también le permite controlar la forma en que se utilizan los datosy los procedimientos.Puede utilizar modificadores de acceso, como Private o Protected, para evitar quelos procedimientosexternos ejecuten métodos de clase o lean y modifiquen datos en propiedades ycampos. Usted debedeclarar los detalles internos de una clase como Private para evitar que seanutilizados fuera de su clase; a

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 14/22

 

esta técnica se le llama ocultamiento de datos. En la clase Bank Account, lainformación del cliente, comoel saldo de la cuenta, se protege de esta forma. Una de las reglas básicas de laencapsulación es que losdatos de la clase sólo se pueden modificar o recuperar a través de los

procedimientos o métodos Property.Ocultar los detalles de implementación de sus clases evita que se usen demaneras no deseadas, y le

permite modificar esos elementos posteriormente sin riesgo de tener problemas decompatibilidad. Porejemplo, versiones posteriores de la clase Bank Account enlistadas más adelante,podrían cambiar el tipode datos del campo Account Balance?, sin peligro de dañar la aplicación quedepende de que este campotenga un tipo de dato específico.Class BankAccount Private AccountNumber As String Private AccountBalance As Decimal Private HoldOnAccount As Boolean = False Public Sub PostInterest() ' Add code to calculate the interest for this account.End Sub ReadOnly Property Balance() As Decimal Get Return AccountBalance 'Returns the available balance.End Get End Property End Class Modularidad:La Modularidad es la propiedad que permite subdividir una aplicación en partesmás pequeñas (llamadasmódulos), cada una de las cuales debe ser tan independiente como sea posible dela aplicación en sí y delas restantes partes.La modularización consiste en dividir un programa en módulos que se puedancompilar por separado, peroque tienen conexiones con otros módulos. Al igual que la encapsulación, loslenguajes soportan laModularidad de diversas formas.La Modularidad es la propiedad de un Sistema que permite su descomposición enun conjunto de móduloscohesivos y débilmente acoplados. Por supuesto no todos los módulos soniguales: tomar un programa

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 15/22

 

monolítico y separarlo de forma aleatoria en archivos no es óptimo. Se debe teneren cuenta los conceptosasociados de dependencia, acoplamiento, cohesión, interfaz, encapsulación yabstracción. Una vezidentificado lo que es un buen módulo, se puede contemplar la reutilización de un

buen módulo comocomponente.El Módulo A depende del Módulo B si cualquier cambio en el Módulo B implica queel Módulo Atambién tenga que ser modificado. A veces se dice que el Módulo A es un clientedel Módulo B, o que elMódulo B actúa como servidor del Módulo A. En general, es normal que un mismomódulo sea tantocliente como servidor. Esto significa, que depende de algunos módulos, mientrasque otros módulosdependen de él. Incluso es posible que un par de módulos se tengan uno al otro

de cliente; sin embargo,éste es un ejemplo de dependencia circular, que debe evitarse cuando sea posibledebido a que impide lareutilización.La dependencia a veces se conoce como acoplamiento. Un Sistema con muchasdependencias tiene fuerteacoplamiento. Los buenos Sistemas tienen débil acoplamiento, porque en esecaso los cambios en unaparte del Sistema son menos probables de propagarse a través del Sistema.Los módulos correctos a menudo tienen la propiedad de que sus interfacesproporcionan una abstracción

de algún elemento conocido de manera intuitiva que puede, no obstante, ser difícilde implementar. Estetipo de módulos se dice que tienen una fuerte cohesión. El módulo realiza unconjunto coherente de cosas,pero dentro de lo posible el desarrollador del cliente está protegido de lainformación irrelevante relativa acómo el módulo hace lo que hace.

Resumiendo: Abstracción es cuando un cliente de un módulo no necesita sabermás de lo que hay en la

interfaz. Encapsulación es cuando un cliente de un módulo no es capaz de sabermás de lo que hay en lainterfaz.Si un módulo, de cualquier tamaño y complejidad, es una buena abstracción (tienefuerte cohesión y débilacoplamiento) puede ser factible reutilizarlo en Sistemas posteriores, o sustituirloen el Sistema existente.Jerarquía

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 16/22

 

La Jerarquía es una propiedad que permite la ordenación de las abstracciones.Las dos jerarquías másimportantes de un Sistema complejo son: estructura de clases (jerarquía “es-un”(is-a):generalización/especialización) y estructura de objetos (jerarquía “parte-de” (part-

of): agregación).Las jerarquías de generalización/especialización se conocen como herencia.Básicamente, la herenciadefine una relación entre clases, en donde una clase comparte la estructura ocomportamiento definido enuna o más clases (herencia simple y herencia múltiple, respectivamente).La agregación es el concepto que permite el agrupamiento físico de estructurasrelacionadas lógicamente.Así, un camión se compone de ruedas, motor, Sistema de transmisión y chasis; enconsecuencia, camiónes una agregación, y ruedas, motor, transmisión y chasis son agregados de

camión.PolimorfismoLa quinta propiedad significativa de los lenguajes de programación orientados aobjetos es elpolimorfismo. Es la propiedad que indica, literalmente, la posibilidad de que unaentidad tome muchasformas. En términos prácticos, el polimorfismo permite referirse a objetos declases diferentes mediante elmismo elemento de programa y realizar la misma operación de diferentes formas,según sea el objeto quese referencia en ese momento.

Por ejemplo, cuando se describe la clase mamíferos se puede observar que laoperación comer es unaoperación fundamental en la vida de los mamíferos, de modo que cada tipo demamífero debe poderrealizar la operación o función comer. Por otra parte, una cabra o una vaca quepastan en un campo, unniño que se come un caramelo y un león que devora a otro animal, son diferentesformas que utilizandiferentes mamíferos para realizar la misma función (comer).El polimorfismo adquiere su máxima expresión en la derivación o extensión declases, es decir, cuando seobtiene una clase a partir de una clase ya existente, mediante la propiedad dederivación de clases oherencia.El polimorfismo requiere ligadura tardía o postergada (también llamada dinámica),y esto sólo se puedeproducir en lenguajes de programación orientados a objetos. Los lenguajes noorientados a objetossoportan ligadura temprana o anterior (también llamada estática), esto significaque el compilador genera

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 17/22

 

una llamada a un nombre específico de función y el enlazador (linker) resuelve lallamada a la direcciónabsoluta del código que se ha de ejecutar. En POO, el programa no puededeterminar la dirección delcódigo hasta el momento de la ejecución. Cuando se envía un mensaje a un

objeto, el código que se llamano se determina hasta el momento de la ejecución. El compilador asegura que lafunción existe y realizaverificación de tipos de los argumentos y del valor de retorno, pero no conoce elcódigo exacto a ejecutar.y ¿Cuáles son los beneficios? , Buena pregunta eh …!!! En resumen, la programación orientada a objetos beneficia a los desarrolladoresdebido a que:Los programas son fáciles de diseñar debido a que los objetos reflejanelementos del mundo real.Las aplicaciones son más sencillas para los usuarios debido a que los datos

innecesarios estánocultos.Los objetos son unidades autocontenidas.La productividad se incrementa debido a que puede reutilizar el código.Los Sistemas son fáciles de mantener y se adaptan a las cambiantesnecesidades de negocios.

Es más fácil crear nuevos tipos de objetos a partir de los ya existentes.Simplifica los datos complejos.

Reduce la complejidad de la transacción.Confiabilidad.Robustez.Capacidad de ampliación.Otras propiedades:El modelo objeto ideal no sólo tiene las propiedades anteriormente citadas sinoque es conveniente quesoporte, además, estas otras propiedades:Concurrencia (multitarea): el lenguaje soporta la creación de procesos paralelosindependientes delSistema operativo.Esta propiedad simplificará la transportabilidad de un Sistema de tiempo real deuna plataforma aotra.Persistencia: los objetos deben poder ser persistentes; es decir, los objetos hande poderpermanecer después de la ejecución del programaGenericidad: las clases parametrizadas (mediante plantillas o unidadesgenéricas) sirven para

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 18/22

 

soportar un alto grado de reutilización.Estos elementos genéricos se diseñan con parámetros formales, que seinstanciarán con parámetrosreales, para crear instancias de módulos que se compilan y enlazan, y ejecutanposteriormente.

Manejo de Excepciones: se deben poder detectar, informar y manejarcondiciones excepcionalesutilizando construcciones del lenguaje. Esta propiedad añadida al soporte detolerancia a fallos delSoftware permitirá una estrategia de diseño eficiente.Taxonomía de lenguajes orientados a objetosUna taxonomía de lenguajes de programación con propiedades de orientación aobjetos fue creada porWegner. La clasificación incluye los siguientes grupos:Basado en objetos: Un lenguaje de programación es basado en objetos si susintaxis y

semántica soportan la creación de objetos que tienen las propiedades descritas enel puntoanterior. Por ejemplo: Ada-83, Clipper 5.2, Visual Basic 4/5/6.Basado en clases: Si un lenguaje de programación es basado en objetos ysoporta además lacreación de clases, se considera basado en clases. Por ejemplo: Clu.Orientación a objetos: Un lenguaje de programación orientado a objetos es unlenguaje basadoen clases que soporta también herencia. Por ejemplo: Visual Basic .NET, C#.NET, C++, Java,Delphi, Eiffel, Simula.

Conceptos de orientación a objetos:Coad y Yourdon definen el término Orientación a Objetos de la siguiente forma:Orientación a Objetos = objetos + clasificación + herencia + comunicaciónClases y Objetos:Un modelo Orientado a Objetos de Software de computadora debe exhibirabstracciones de datos yprocedimientos que conducen a una Modularidad eficaz. Una clase es unconcepto Orientado a Objetosque encapsula las abstracciones de datos y procedimientos que se requieren paradescribir el contenido ycomportamiento de alguna entidad del mundo real.

Las abstracciones de datos (atributos) que describen la clase están encerradaspor una “muralla” de abstracciones procedimentales (llamadas operaciones, métodos o servicios)capaces de manipular losdatos de alguna manera. La única forma de alcanzar los atributos (y operar sobreellos) es ir a través dealguno de los métodos que forman la muralla. Por lo tanto, la clase encapsuladatos (dentro de la muralla)

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 19/22

 

 

y el proceso que manipula los datos (los métodos que componen la muralla). Estoposibilita la ocultaciónde información y reduce el impacto de efectos colaterales asociados a cambios.Nota: Un objeto encapsula datos (atributos) y los métodos (operaciones, métodoso servicios) quemanipulan esos datos.Atributos:Los atributos están asociados a clases y objetos, y describen la clase o el objetode alguna manera. Lasentidades de la vida real están a menudo descritas con palabras que indicancaracterísticas estables. Lamayoría de los objetos físicos tienen características tales como forma, peso, colory tipo de material. Laspersonas tienen características como fecha de nacimiento, padres, nombre y colorde los ojos. Unacaracterística puede verse como una relación binaria entre una clase y ciertodominio.La “relación” binaria implica que un atributo puede tomar un valor definido por undominio enumerado.En la mayoría de los casos, un dominio es simplemente un conjunto de valoresespecíficos. Por ejemplo,supongamos que una clase Coche tiene un atributo color. El dominio de valores decolor es blanco, negro,plata, gris, azul, rojo, amarillo, verde.Las características (valores del dominio) pueden aumentarse asignando un valorpor defecto(característica) a un atributo. Por ejemplo, el atributo color tiene el valor pordefecto negro.Nota: Los valores asignados a los atributos de un objeto hacen a ese objeto serúnico.Operaciones, métodos y servicios:Un objeto encapsula datos (representados como una colección de atributos) y losalgoritmos que procesanestos datos. Estos algoritmos son llamados operaciones, métodos o servicios ypueden ser vistos como

módulos en un sentido convencional.Cada uno de los métodos encapsulados por un objeto proporciona unarepresentación de uno de loscomportamientos del objeto. Por ejemplo, el método Determinar Color?, para elobjeto Coche extraerá elcolor almacenado en el atributo color. La consecuencia de la existencia de esemétodo es que la clase

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 20/22

 

coche ha sido diseñada para recibir un estímulo (mensaje) que requiere el color deuna instancia particularde una clase. Cada vez que un objeto recibe un estímulo, éste inicia un ciertocomportamiento, que puedeser tan simple como determinar el color del coche o tan complejo como la

iniciación de una cadena deestímulos que se pasan entre una variedad e objetos diferentes.Nota: Siempre que un objeto es estimulado por un mensaje, inicia algúncomportamiento ejecutando unmétodo.Mensajes:Los mensajes son el medio a través del cual interactúan los objetos. Un mensajeestimula la ocurrencia decierto comportamiento en el objeto receptor. El comportamiento se realiza cuandose ejecuta un método.Una operación dentro de un objeto emisor genera un mensaje de la forma:

destino.operación (parámetros)Donde destino define al objeto receptor el cual es estimulado por el mensaje,operación se refiere almétodo que recibe el mensaje y parámetros proporciona información requeridapara el éxito de laoperación.Los mensajes proporcionan una visión interna del comportamiento de objetosindividuales, y del SistemaOrientado a Objetos como un todo.Nota: El paso de mensajes mantiene comunicado un Sistema orientado a objetos.3.2.1 Análisis

El modelo de análisis se extiende luego para describir la manera en queinteractúan los actores y elSistema para manipular el modelo del dominio de aplicación. Los desarrolladoresusan el modelo de

análisis, junto con los requerimientos no funcionales, para preparar la arquitecturadel Sistema que sedesarrolla durante el diseño de alto nivel.Las actividades del análisis: la identificación de objetos, su comportamiento, susrelaciones, suclasificación y su organización.El modelo de análisis está compuesto por tres modelos individuales: el modelofuncional, representado porcasos de uso y escenarios, el modelo de objetos de análisis, representado pordiagramas de clase y objeto,y el modelo dinámico, representado por gráficas de estado y diagramas desecuencia.Conceptos de análisis:

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 21/22

 

Particularmente describimos:Objetos de entidad, frontera y control: Los objetos de entidad representan lainformación persistenterastreada por el Sistema. Los objetos de frontera representan la interacción entrelos actores y el Sistema.

Los objetos de control representan las tareas realizadas por el usuario ysoportadas por el Sistema.Multiplicidad de asociación: el extremo de una asociación puede etiquetarse comoun conjunto de enterosllamados multiplicidad. La multiplicidad indica la cantidad de vínculos que puedenoriginarselegítimamente desde una instancia de la clase conectada al extremo de laasociación.En UML, un extremo de una asociación puede tener como multiplicidad unconjunto de enterosarbitrarios. Sin embargo, en la práctica, la mayoría de las asociaciones que

encontramos pertenece aalguno de los siguientes tres tipos:Una asociación de uno a uno tiene una multiplicidad de 1 a cada extremo. Unaasociación de uno a unoentre dos clases significa que existe solamente un vínculo entre instancias decada clase.Una asociación de uno a muchos tiene una multiplicidad de 1 en un extremo y0…n Una asociación de uno a muchos entre dos clases (por ejemplo, Persona yAutomóvil) indica composiciónUna asociación de muchos a muchos tiene una multiplicidad de 0. . n o 1. . n en

ambos extremos. Unaasociación de muchos a muchos entre dos clases indica que puede existir unacantidad arbitraria devínculos entre instancias de las dos clases. Este es el tipo más complejo deasociación.Asociaciones calificadas:La calificación es una técnica para la reducción de la multiplicidad usando claves.Las asociaciones quetienen multiplicidad de 0…1 o 1 son más fáciles de comprender que lasasociaciones con multiplicidad de0…n o 1…n. Con frecuencia, en el caso de una asociación de uno a muchos, losobjetos del lado de“muchos” pueden distinguirse entre ellos usando un nombre. Generalización:La generalización nos permite organizar conceptos en jerarquías.El análisis para el enfoque orientado a objetos; En lugar de considerar el SWdesde una perspectiva básicade entrada-proceso-salida como los métodos estructurados se basa en modelar elSistema mediante los

5/17/2018 Unidad III Paradigm As de La Ingenieria de Software - slidepdf.com

http://slidepdf.com/reader/full/unidad-iii-paradigm-as-de-la-ingenieria-de-software 22/22

 

objetos que forman parte de él y las relaciones estáticas (herencia y composición )o dinámicas(uso entreotros objetos ). El análisis identifica las clases y objetos relativamente en eldominio del problema, eldiseño proporciona detalles sobre la arquitectura, las interfaces y los componentes

la implementacióntransforma el diseño en código y la pruebas checan tanto la arquitectura como lainterfaz y loscomponentes.3.2.2 DiseñoDurante el diseño de objetos cerramos el hueco entre los objetos de aplicación ylos componentes hechos,identificando objetos de solución adicionales y refinando los objetos existentes.

El diseño de objetos incluye:• Especificación de servicios, durante la cual describimos con precisión cadainterfaz de clase.• Selección de componentes, durante la cual identificamos componentes hechos yobjetos de soluciónadicionales.• Reestructuración del modelo de objetos, durante la cual transformamos elmodelo de diseño de objetospara mejorar su comprensibilidad y extensibilidad.• Optimización del modelo de objetos, durante la cual transformamos el modelo dediseño de objetos paratratar criterios de desempeño, como el tiempo de respuesta o la utilización de lamemoria.El diseño de objetos, al igual que el diseño del Sistema, no es algorítmico.El diseño de objetos a veces es difícil distinguir claramente el análisis y el diseñoOrientado a Objetos(OO).Esencialmente AOO es una actividad de clasificación, se analiza un problema conel fin de determinarclases de objetos que sea aplicables en el desarrollo de la solución.El de DOO permite al ing. de SW los objetos que se derivan de cada clase de lasinterrelaciones entre ellosy proporciona una notificación que refleja las relaciones entre los objetos.