Hogar › Servicios › Objetos, atributos y claves. Tipos de atributos de objetos. Modelado de objetos similares.

Objetos, atributos y claves. Tipos de atributos de objetos. Modelado de objetos similares.

2.1.2. Atributos de objeto

Un atributo es un valor que caracteriza a un objeto en su clase. Ejemplos de atributos: categoría, saldo, crédito (atributos de objetos de la clase de cuenta); nombre, edad, peso (atributos de los objetos de la clase de persona), etc.

Los atributos varían atributos permanentes(constantes) y atributos variables. Los atributos constantes caracterizan un objeto en su clase (por ejemplo, número de cuenta, categoría, nombre de la persona, etc.). Los valores actuales de las variables de atributos caracterizan la corriente. estado objeto (por ejemplo, saldo de cuenta, edad de la persona, etc.); Al cambiar los valores de estos atributos, cambiamos el estado del objeto.

Los atributos se enumeran en la segunda parte del rectángulo que representa la clase (ver Figura 2.1). A veces se indica el tipo de atributos (después de todo, cada atributo tiene un valor determinado) y el valor inicial de los atributos variables (el conjunto de valores iniciales de estos atributos especifica el estado inicial del objeto).

Cabe señalar que cuando hablamos de objetos y sus clases, no nos referimos a ningún lenguaje de programación orientado a objetos. Esto se refleja, en particular, en el hecho de que en esta etapa Al desarrollar un sistema de software, se deben considerar solo aquellos atributos que en realidad tienen sentido (todos los atributos de los objetos de la clase de cuenta - Figura 2.1 - tienen esta propiedad). Los atributos están asociados con características de la implementación general. Por ejemplo, si sabe que utilizará una base de datos en la que cada objeto tiene identificador único, entonces este identificador no debe incluirse entre los atributos del objeto en esta etapa. El hecho es que al introducir tales atributos, limitamos las posibilidades de implementar el sistema. Por lo tanto, al introducir un identificador de objeto único en la base de datos como atributo, desde el comienzo del diseño nos negamos a utilizar DBMS que no admitan dicho identificador.

Los matemáticos son demasiado vagos para explicar en lenguaje sencillo qué numero real. Es difícil para la persona promedio leer los símbolos escritos por un matemático porque su significado no le resulta claro. Como resultado, existe una brecha entre la teoría y la práctica. En teoría, los matemáticos saben muy bien qué tipos de objetos son y qué atributos son, pero, bajando a la práctica, vemos que pocos practicantes entienden qué son. Hay muchos conceptos intuitivos, pero cada uno de ellos se parece más a un dogma religioso que a un conocimiento. En este artículo intenté cerrar la brecha entre matemáticos y científicos aplicados explicando los conceptos básicos de la teoría de conjuntos. en lenguaje sencillo, sin iconos complicados. Por ejemplo, ¿está familiarizado con la definición de atributo? Yo mismo lo sufrí porque no pude encontrar una definición formal de ello. Y solo entonces Igor Katrichek me envió un enlace al libro de E. Kindler "Modeling Languages" (1979, traducido en 1985), que da la definición de atributo:

En este artículo daré mi, más definición general atributo para que puedas imaginarlo fácilmente.

En el último artículo hablé del hecho de que en nuestra mente existen varios objetos que consideramos como un todo, pero que no reconocemos explícitamente. Los matemáticos se dieron cuenta de esto y lo hicieron explícito al introducir el concepto de conjunto. También recordé que el concepto muchos y concepto objeto- axiomas que no pueden derivarse de otros conceptos. Al mismo tiempo, el concepto de objeto nos resulta familiar y tenemos suficiente experiencia para trabajar con ellos, pero nos familiarizamos con un conjunto en el instituto cuando estudiamos los fundamentos de las matemáticas, y la idea de ellos es no tan obvio. Para aquellos que estén buscando una oportunidad de aprender a representar un conjunto más claramente, les he dicho dónde podemos encontrar buena imagen– en la presentación de estructuras. En este artículo continuaré la historia sobre los decorados y les contaré qué tipo Y atributo desde el punto de vista de la teoría de conjuntos. Y lo más importante, te diré cómo se reflejan estos conceptos en los modelos que construimos.

Conjuntos en matemáticas y física.

Percibimos el mundo como espacio o como tiempo, pero no podemos imaginar ambos al mismo tiempo. Esto impone sus limitaciones al lenguaje que utilizamos y a los modelos que construimos.

Por ejemplo, un conjunto matemático no existe en el tiempo, al igual que las operaciones sobre él. Esto significa que no se puede decir que la composición del conjunto cambie con el tiempo.

Esto me parece un requisito contrario a la intuición y no obvio, pero sin él no podremos realizar operaciones en conjuntos ni hacer comparaciones. Esto significa que si queremos describir un conjunto de granos de arena en un montón de arena, entonces tenemos dos formas de hacerlo: para cada nueva composición de granos de arena, introducir un nuevo conjunto, o considerar el conjunto de partes temporales. de granos de arena en el montón en estudio. La parte temporal de un grano de arena se refiere al tiempo A Soy parte de un grano de arena que tiene un atributo: principio y fin, modelando la presencia de este grano de arena en el montón. Este conjunto de partes temporales también se denomina representación 4D realizada en el paradigma 4D. La composición de los granos de arena en un momento específico se puede obtener a partir de este conjunto ohª rebanada: seleccione solo aquellas partes temporales de granos de arena que están "actuales" en en este momento tiempo, es decir, aquellos que aparecieron en el montón antes y abandonaron el montón más tarde que el momento seleccionado.

Así se modela la composición de conjuntos “físicos” reales. Pero para el presente artículo, tal representación será bastante compleja, y volveré a la representación habitual de conjuntos simples "congelados" en el tiempo, es decir, aquellos que existen "fuera del tiempo".

Determinar la composición de un conjunto.

Un conjunto es un lote, concebido como un todo, donde el lote es la composición de un conjunto. Consideremos formas de determinar la composición de un conjunto. Como sabemos, la composición de un conjunto se puede especificar de dos formas:

Enumeración directa de objetos seleccionados de un conjunto.
Reglas para identificar objetos seleccionados de un conjunto.

Por ejemplo, supongamos que hay dos objetos en la habitación, entre otros objetos: un plato blanco y un marcador verde.

Un conjunto A que consta de estos dos elementos se puede definir mediante enumeración: el plato blanco es parte del conjunto A y el marcador verde es parte del conjunto A. Nada más en la habitación es parte del conjunto A.
Puedes hacerlo de otra manera. Puedes pegar una pegatina amarilla al plato y al marcador y asegurarte de que no haya otras pegatinas en la habitación. Entonces podemos decir que aquellos y sólo aquellos objetos de una habitación determinada que tienen una pegatina amarilla están incluidos en el conjunto A.

La primera forma de determinar la composición es enumerar
El segundo método consiste en establecer la condición de identificación.

Durante la discusión del último artículo, me di cuenta de que no todos entienden claramente la diferencia entre estas dos formas de determinar la composición de un conjunto. Por eso, te contaré más sobre ellos.

El primer método se basa en una serie de afirmaciones:

La placa es parte del conjunto A.
El marcador es parte del conjunto A.
Nadie más forma parte del conjunto A.

La segunda forma es una declaración en predicados:

Ese y sólo aquel objeto de la habitación que tiene una pegatina amarilla está incluido en el set A.

El primer método para describir la composición puede implicar cualquier modelo de objeto. En el segundo método de descripción, los modelos de objetos deben tener un atributo común, cuyo valor determina si el objeto está incluido o no en el conjunto. Es decir, si no hay objetos en los modelos. atributos comunes, es imposible construir condiciones de identificación.

En la discusión, se propuso que la misma inclusión en el conjunto, mediante una enumeración, también debería convertirse en un atributo: “parte del conjunto A”. Así, aquellos objetos que están incluidos en el conjunto A tienen el valor de este atributo “sí”. Luego se propuso, en base a este atributo, hacer un signo de selección en el mismo conjunto A: aquellos objetos que tienen el valor "sí" se incluyen en el conjunto A. El autor de esta idea no se dio cuenta de que como resultado De la conclusión lógica de estas dos afirmaciones obtenemos dos tautologías:

El conjunto A incluye aquellos y sólo aquellos objetos que están incluidos en el conjunto A. Y

Un objeto está incluido en el conjunto A si y sólo si está incluido en el conjunto A.

Estas declaraciones obvias no contienen información sobre objetos específicos, ni sobre el conjunto A. Si tomo un plato, basándose en esta afirmación no será posible determinar si pertenece al conjunto A o no.

Por lo tanto, enumeración y regla son dos aspectos fundamentalmente. diferentes maneras descripciones de la composición de un conjunto, y en matemáticas se indican como dos formas principales y completamente diferentes de determinar la composición de un conjunto.

Por cierto, hubo un tiempo en el que hubo un largo debate sobre la definición de qué es una función. Esta disputa surgió porque no podían decidir qué reglas de identificación se consideraban correctas y cuáles no. Como resultado, se aceptó la idea de Dirichlet de que cualquier regla se consideraría correcta. Por eso no intentaré clasificar todas las reglas, sino que consideraré sólo algunas que necesitaremos en este contexto.

En los libros de texto, la regla de identificación suele denominarse regla de selección. El término "regla de selección" es engañoso porque implica algún tipo de operación de selección. Y esto es un indicio de que es posible que el conjunto se reponga. Pero eso no es cierto. El conjunto tiene una composición fija. Por tanto, es mejor hablar no de selección, sino de identificación. No seleccionamos elementos en un conjunto, los identificamos como elementos del conjunto.

Determinar la composición de un subconjunto

Veamos cómo determinamos la composición de muchos elefantes africanos. Conté cuatro formas diferentes de hacer esto.

Puede definirlos mediante enumeración.
Se puede poner una pegatina a los elefantes y decir que aquellos elefantes que tienen una pegatina se consideran africanos. Se trata de la determinación de la composición de un conjunto a través de un atributo. Se considerará atributo la presencia o ausencia de una pegatina.
Se puede determinar la composición a través de la intersección de dos conjuntos: el conjunto de los elefantes y el conjunto de los animales que viven en África.
Puedes introducir un concepto como “elefantes africanos”.

Usando OWL en nuestro trabajo, tenemos la oportunidad de implementar los tres métodos descritos anteriormente para especificar un subconjunto:

Enumere explícitamente los objetos incluidos en el subconjunto,
Defina una regla de identificación a través de cualquier condición sobre cualquier atributo, con diferentes operaciones: desde el hecho mismo de poseer el valor de un atributo hasta que este valor cae dentro de un rango determinado
Especifique operaciones en otros conjuntos: por ejemplo, el conjunto A incluye solo aquellos objetos que están incluidos en el conjunto B y no están incluidos en el conjunto C.

Para comprender si podemos implementar el cuarto método de identificación utilizando un tipo de objeto, echemos un vistazo más de cerca.

Modelar un subconjunto usando un tipo

Para determinar el tipo de “elefante africano” necesitamos:

Un grupo de objetos del cual seleccionamos objetos para un subtipo. EN en este caso Este grupo tiene un nombre: es un grupo de elefantes.
Una propiedad única en la que los objetos de este tipo se diferencian de otros objetos del grupo: viven en África.
Nombre único para objetos. de este tipo

Puedes hacerlo de otra manera y tomar animales que viven en África como grupo. Entonces, la propiedad única que distingue a los elefantes africanos de otros animales africanos será que estos animales son elefantes.

En total, para definir un tipo, necesita:

Especifique un superconjunto de objetos.
Especificar características distintivas(propiedades diferenciales) de objetos de un tipo determinado de objetos de un grupo.
Especifique el nombre de los objetos de este tipo.

Además puedes especificar:

Las razones por las que este tipo de objetos se volvieron populares (propiedades funcionales diferenciales de objetos de este tipo
Los beneficios de introducir este tipo de objetos
Historia del término

Los objetos del mismo tipo se diferencian de otros objetos del superconjunto por alguna propiedad única. Esta propiedad única se puede modelar mediante cualquier condición en cualquier atributo. Pero no es necesario que todos los valores de todos los atributos coincidan, ni que la composición de atributos de todos los objetos del mismo tipo sea la misma.

Sabiendo qué es un tipo, se podría pensar que el cuarto método de identificación de subconjuntos coincide con el segundo. Sin embargo, para definir un tipo, necesitaremos adicionalmente, como mínimo, indicar un nombre especializado y, como opción, indicar otros atributos del tipo, por ejemplo, indicar los motivos para seleccionar este tipo de objeto, el historial. del término, etc. Esto no se puede hacer usando el segundo método. Por lo tanto, el cuarto método difiere del segundo y aún no está implementado en los estándares de modelado que yo sepa.

Tipo de concepto

Entonces, desde el punto de vista de la teoría de conjuntos:

Un tipo es una forma de seleccionar un subconjunto de un superconjunto y asignar un nuevo nombre a los objetos de este subconjunto.

Si no hay superconjunto, entonces el tipo se considera axiomático, no derivable. Como dije antes, el concepto de objeto y el concepto de conjunto son conceptos no derivables porque no se les puede dar un superconjunto de objetos.

Diferencia entre tipo de objeto y conjunto de objetos

De las discusiones sobre el artículo, me di cuenta de que hay personas que creen que el tipo de objetos y el conjunto de objetos son conceptos relacionados o uno y el mismo. Intentaré explicar por qué esto no es así. Un tipo es a la vez una regla para identificar objetos y un nombre para esos objetos. Es decir, el tipo sirve simultáneamente para especializar (o seleccionar) un subconjunto de un conjunto y da un nuevo nombre a los objetos especializados.

Cada tipo determina la composición de un conjunto, pero no todo conjunto corresponde a un tipo que determina su composición, por ejemplo, cuando hablamos de un conjunto cuya composición viene dada por la enumeración de sus elementos, o cuando hablamos de un conjunto cuyos elementos no no tener nombres propios.

Está claro que la regla que define un conjunto no es el conjunto en sí.

Me parece que de todo lo dicho se desprende claramente en qué se diferencia el concepto de “tipo de objetos” del concepto de “conjunto de objetos”.

Modelado de objetos similares.

A menudo, en SI, los objetos del mismo tipo se modelan utilizando modelos que contienen el mismo conjunto de atributos. Ahora puedes ver eso esta limitación redundante, ya que los objetos del mismo tipo pueden tener diferentes conjuntos de atributos. Esta limitación es causada características técnicas implementaciones, pero no requisitos área temática.

En el IS la lista de objetos del mismo tipo va en aumento. Esto sugiere la composición variable de los conjuntos que estamos modelando. Sin embargo, esto no es cierto. La lista de objetos que se han registrado en la IP no es una lista exhaustiva del conjunto. Es decir, el IS no almacena modelos de todos los elementos del conjunto, sino sólo aquellos que están registrados actualmente. Por lo tanto, cuando hacemos una solicitud, su significado es este: dame todos los objetos de este tipo que están actualmente registrados en el IS.

Ciclo de vida del objeto

Además del hecho de que un objeto puede clasificarse como un cierto tipo objetos, hay dos puntos más que no se deben olvidar:

Clasificación (asignar un objeto a una cierta clase, o tipo de objetos) es siempre subjetivo. Un mismo objeto puede verse diferente desde diferentes puntos de vista. Si estamos construyendo un modelo de dominio extensible, cuyo uso implica la presencia de diferentes partes interesadas, entonces debe ser posible modelar el contexto y los diferentes puntos de vista. Además, desde distintos puntos de vista, un mismo objeto puede clasificarse en distintos tipos.
Contabilidad ciclo vital de un objeto implica no sólo tener en cuenta los cambios en el objeto, sino también tener en cuenta los cambios en nuestra percepción de ese objeto, ya que junto con el proceso de síntesis y análisis hay un proceso de objetivación y desobjetivación.

El proceso de objetivación y desobjetivación se ve así:

Cosificación

Teniendo una idea de los tipos, intentamos encontrar objetos de estos tipos en el mundo que nos rodea. Los objetos encontrados tienden a ser de los tipos más amplios. Por ejemplo, si estamos hablando de sobre la empresa, luego, en el primer paso, los objetos encontrados pueden relacionarse con operaciones, funciones y objetos. O si hablamos de plantas, primero las dividimos en árboles, pasto y arbustos. A continuación, se aclara el tipo de objeto probando varias hipótesis. En el proceso de aclaración, estamos tratando de encontrar un tipo que nos diga lo suficiente sobre el objeto para que este conocimiento pueda usarse efectivamente en la práctica (estamos tratando de encontrar un tipo más limitado al que se le pueda atribuir este objeto). En el proceso de perfeccionamiento, el modelo de objeto adquiere nuevos detalles. Al mismo tiempo, utilizamos nuestros conocimientos sobre este objeto en la práctica. Si la aplicación de este conocimiento tiene éxito, el objeto se considera correctamente obtenido y correctamente clasificado (el tipo de objeto se elige correctamente).

Desobjetivación

Sin embargo, todo cambia: cambian las ideas sobre el mundo que nos rodea, aparecen nuevos conocimientos, etc. Como resultado, resulta que el modelo del objeto deja de satisfacer el requisito de utilidad. Y entonces una especialización demasiado estrecha del objeto se convierte en su propio enemigo. El objeto está sujeto a reclasificación (la aplicación se ha convertido en una demanda) y, en ocasiones, se destruye por completo, como se destruyó el éter o el calórico. Y luego el ciclo comienza de nuevo: seleccionar objetos, aclarar conocimientos sobre ellos, etc.

Estudios de caso:

Objetificación:

Deje que el cliente venga a presentar una solicitud. Hasta que se ejecute la orden, sólo podemos conocer su tipo con cierto grado de probabilidad. Por tanto, se registra en primer lugar la solicitud del tipo más amplio. Luego, a medida que se aclaran los detalles y en el proceso de su ejecución, el modelo de aplicación adquiere nuevos atributos. Después de un tiempo, queda claro qué tipo de aplicaciones incluir esta aplicación y se produce su clasificación final.

Desobjetivación:

Imaginemos un escenario típico de búsqueda de información en Internet. Que digamos que siempre que necesite encontrar la información que necesita, utilice tal o cual motor de búsqueda: un programa de búsqueda. información necesaria. Utilicemos este programa muchas veces, realizando cada vez una operación de búsqueda. Hubo muchas operaciones de este tipo durante la operación de este programa, y todas ellas fueron clasificadas como operaciones del tipo “búsqueda de información”. Después de un tiempo, resulta que el programa del motor de búsqueda realiza funciones de espionaje, “filtrando” datos sobre el usuario a las personas interesadas en esta información. Y luego resulta que aquellas operaciones que utilizaba este buscador ahora serán reclasificadas de operaciones de recuperación de información a operaciones de transferencia de datos. partes interesadas. Pero puede suceder que aprendamos algo más sobre este programa y luego tengamos que reconsiderar otras operaciones en las que participó.

Requisitos para un modelador de tipos de modelado.

Formulemos los requisitos para un modelador diseñado para modelar tipos:

Es necesario poder modelar objetos del mismo tipo cuya composición de atributos no coincida.

Debe poder modelar reglas que distingan los objetos en un tipo.

La necesidad de modelar otros atributos de un tipo: el nombre de los objetos de un tipo determinado, el historial de este nombre, etc.

Debe poder modelar diferentes puntos vista del mismo objeto

Debes poder modelar el ciclo de vida de un objeto.

Es necesario poder modelar cambios en nuestra comprensión de un objeto a lo largo del tiempo.

¿Cómo puede la industria de TI implementar estos requisitos sin recurrir a la estructura de la base de datos? ¿Cómo, sin hacer referencia a la estructura de datos, tener en cuenta diferentes puntos de vista, agregar nuevos tipos de objetos, aclarar el tipo de objetos, reclasificar objetos si es necesario?

Modelar objetos con OWL

Hay una limitación que está presente en OWL: no distingue entre el conjunto y el tipo de objetos. Debido a esto, tenemos una funcionalidad limitada para modelar tipos de objetos. Sin embargo, esta funcionalidad es mucho más amplia que la que nos brindan otros métodos de modelado, porque contamos con las siguientes capacidades:

Agregar un nuevo conjunto de objetos a OWL no es diferente de agregar un nuevo objeto.
Se puede exigir que, si se conoce el tipo de un objeto, se cree un modelo del objeto con atributos dados y previamente conocidos. Además, después de la creación, los atributos se pueden agregar o eliminar. Ejemplo: al crear un modelo de solicitud, es posible que solicitemos que se especifiquen los valores de los atributos (número de solicitud, fecha de solicitud, solicitante, destinatario). Sólo necesitas recordar que estos atributos en OWL existen por separado de los tipos de objetos. Y se puede utilizar un atributo al modelar objetos de diferentes conjuntos. Este diferencia fundamental de lenguajes de programación comunes, donde un atributo existe solo dentro de un tipo de objeto. Otro atributo de un tipo diferente, incluso con el mismo nombre, será un atributo diferente.
Puede requerir lo contrario: determinar un subconjunto del objeto modelado en función de los atributos del modelo de objetos y su pertenencia al superconjunto. Para hacer esto, la regla escribirá que si el modelo de un objeto que pertenece a un determinado superconjunto contiene tales o cuales atributos y sus valores satisfacen ciertas reglas, entonces el objeto se asignará automáticamente a un determinado subconjunto. Así, con la ayuda de reglas, se implementará la llamada "clasificación de patos". Por ejemplo, si el modelo de solicitud tiene el valor de atributo " Número de teléfono”, y “Conexión” es el valor del atributo “Tipo de trabajo realizado”, entonces la aplicación se clasificará automáticamente como una solicitud para conectar un número de teléfono.

Dividir un conjunto en subconjuntos

Sea un conjunto de objetos. Y que la tarea sea dividir este conjunto en siete subconjuntos, a cada uno de los cuales se le asigna su propio color: “objetos rojos”, objetos amarillos”. Etc.

La división de un conjunto en subconjuntos se puede realizar de diferentes formas.

Puede dividir un conjunto en subconjuntos disjuntos distribuyendo objetos en subconjuntos enumerándolos. Crea siete subconjuntos y enumera los objetos que pertenecen a cada subconjunto.
Para cada subconjunto puedes crear tu propio subtipo. Luego, todo el conjunto se puede dividir en siete subconjuntos introduciendo siete subtipos: "Tipo de objetos rojos", "Tipo de objetos amarillos", etc. Cada objeto se puede atribuir a uno de los tipos enumerados y decir, por ejemplo, así : el objeto pertenece al tipo de objetos rojos.
Puede separar un superconjunto utilizando un atributo y sus valores. Por ejemplo, puedes ingresar el atributo “Color” y sus siete valores: “Rojo”, “Amarillo”, etc. Entonces el nombre del color se convertirá en un adjetivo para el objeto y sonará así: objeto rojo, objeto amarillo, etc.

El primer método en OWL se implementa creando siete diferentes clases e indicaciones de los objetos que se refieren a ellos.

El segundo método se puede implementar de tres formas diferentes:

Creando subconjuntos separados unidos por un tipo, pero los tipos en sí, como dije antes, no se modelan. Este método no es diferente del método de separación por enumeración.
Utilizando el libro de referencia "Tipos de objetos coloreados", cuyos valores serán objetos que modelen los tipos: "Objetos rojos", "objetos amarillos", etc.
Utilizando un atributo llamado “tipo de objeto”, cuyos valores tendrán forma de texto: “Tipo de objetos rojos”, “Tipo de objetos amarillos”, etc.

La tercera forma de dividir un conjunto en subconjuntos en un SI se modela de dos maneras:

Utilizando el directorio “Colores”, cuyos valores serán objetos que modelan los valores de los atributos: rojo, amarillo, etc.
Utilizando un atributo llamado “Color”, cuyos valores estarán en forma de texto: “rojo”, “amarillo”, etc.

Se puede ver que la separación mediante tipos y atributos se modela en dos casos. del mismo modo, pero tiene diferentes nombres. De hecho, la propiedad de un valor de atributo en OWL se modela mediante el siguiente triplete:

#objeto #atributo #valor

La membresía de la clase es la siguiente:

#objeto rdf:tipo #clase

Es decir, podemos decir que la pertenencia a una clase se expresa simplemente mediante un atributo de servicio especial definido en el estándar: rdf:type.

Concepto de atributo

Formulemos el enunciado:

Un atributo es una forma de dividir un conjunto de objetos en subconjuntos. En este caso, cada valor de atributo corresponde a un subconjunto específico, cuyos objetos tienen un atributo con ese valor.

Modelado de subconjuntos usando un atributo

Cada uno de los tres métodos de modelado de subconjuntos enumerados anteriormente tiene sus propias ventajas y desventajas según el contexto y el método de implementación elegido.

Si hay pocos subconjuntos, puede elegir cualquiera de los métodos enumerados para dividir en subconjuntos y cualquier implementación.

Si hay muchos subconjuntos (en el límite infinito, por ejemplo, cuando cada uno de los conjuntos agrupa objetos de la misma longitud), entonces formalmente queda lo siguiente:

tercera forma de modelar el tipo y
la segunda forma de modelar el atributo.

Sin embargo, escribí anteriormente que a cada tipo se le debe dar un nombre. Si hay muchos subconjuntos (infinitos), entonces darle un nombre a cada uno de ellos no es realista. Por lo tanto, no modelamos esta división usando tipos. Modelamos esta división únicamente con la ayuda de un atributo cuyo rango de valores será uno de los conjuntos comunes: set números reales, un conjunto que modela una línea de tiempo, un conjunto números naturales, muchas cadenas de longitud finita, etc. ¿Reconoces los tipos de datos?

Puede leer sobre cómo introducir una función en un conjunto de subconjuntos y no solo sobre eso.

Los atributos de objetos comerciales contienen datos asociados con objetos comerciales. El atributo almacenado representa una columna de una tabla de base de datos o una columna de vista de base de datos. El valor de un atributo no persistente existe sólo en la memoria porque los datos asociados con el atributo no se almacenan en la base de datos.

Un objeto comercial almacenado puede tener atributos almacenados y no almacenados. Los atributos almacenados de un objeto comercial están asociados con columnas en una tabla o vista de base de datos. Todos los atributos de los objetos comerciales no persistentes son atributos no persistentes.

Además de la información básica sobre el tipo de datos, el producto almacena metadatos adicionales asociados con los atributos del objeto comercial. Por ejemplo, un atributo puede tener un dominio, una clase personalizada o un valor predeterminado; puede especificar que un atributo sea un atributo obligatorio.

Restricciones de atributos

Antes de cambiar un atributo, puede verificar si fue creado por el sistema o por alguien en su sitio. Los atributos generados por el sistema tienen más restricciones de cambios que los atributos creados por el usuario. Un atributo generado por el sistema no se puede eliminar.

En escenarios de integración, los datos de un objeto comercial se pueden obtener de programas comerciales externos. Se pueden utilizar restricciones de cambios de atributos para evitar que los datos externos sobrescriban el valor del atributo.

Algunas restricciones dependen de si búsqueda de texto objeto o buscar por tipo de datos. Las reglas que rigen los cambios dependen del atributo. Por ejemplo, algunos tipos de datos tienen valor establecido por longitud, escala, fechas o números enteros. Los datos en el campo Nota son datos ALN normales y el campo no contiene ningún valor restringido.

Para gestionar las restricciones de atributos, puede hacer lo siguiente:

Ver restricciones sobre los atributos del objeto actual
Limitar atributos de objetos
Eliminar restricciones sobre los atributos de los objetos

MINISTERIO DE EDUCACIÓN Y CIENCIA DE LA FEDERACIÓN DE RUSIA

Estado institución educativa más alto educación vocacional

Universidad Económica Rusa que lleva el nombre de G.V. Plejánov

Instituto Ufa (sucursal)

Facultad de Economía y Gestión

Curso 2

Especialidad 230700.62 informática aplicada

Gabbasov Timur Aidarovich

Trabajo de curso

Disciplina: "Ingeniería de Software"

Sobre el tema: “El concepto de clase y objeto. ¿Qué podría ser un objeto? Atributos y Operaciones"

Jefe: Sadrtdinov F.A.

Ufá 2014

Introducción…………………………………………………………………………………….3

1. El concepto de objeto en programación …………………………………4

2. Definición de clase…………………………………………………………..6

2.1.Atributos de las clases…………………………………………………………..7

2.2.Operaciones……………………………………………………………….8

2.3 Dependencias entre clases y objetos…………………………..11

Conclusión…………………………………………………………………………………….15

Lista de referencias…………………………………………………….17

Introducción

Relevancia de este trabajo.La razón es que gracias a conceptos como "Objeto" y "Clase", la programación orientada a objetos apareció como un enfoque sistemático para la formalización algorítmica de áreas temáticas complejas, lo que simplificó enormemente la solución de problemas voluminosos.

Tema de investigación -concepto de clase y objeto.

Objeto de estudio -objeto y clase, y su relación con atributos y operaciones.

El propósito de este trabajo:revelar la esencia de los conceptos objeto y clase, indicar su conexión con los conceptos de atributo y operación, indicar su papel en el concepto de programación orientada a objetos.

Tareas:

1.Aprender los conceptos de objeto y clase.

2.Da ejemplos
3.Estudiar los conceptos de atributo y operación.

4.Indique el papel en Conceptos de programación orientada a objetos.

1. El concepto de objeto en programación.

En cualquier lenguaje de programación prescriptivo ordinario, se distinguen conceptos como datos y tipos de datos. Los datos son números, cadenas de caracteres, varios códigos binarios, que se pueden almacenar en la RAM de la computadora y se pueden realizar diversas operaciones sobre ellos. Los tipos de datos son los nombres de grupos de datos que tienen el mismo tamaño, ocupación en RAM y método de representación externa, por ejemplo, números enteros o caracteres.

Existe una división similar en los lenguajes de programación orientados a objetos. Un objeto es el concepto más cercano al concepto de datos. Esto es algo que realmente debe existir en el programa, ocupando un espacio determinado por su tipo. RAM. Al mismo tiempo, el objeto es más concepto complejo que simplemente un dato determinado o un conjunto de datos. De manera más simple, un objeto podría denominarse una colección inextricable de datos con un conjunto de funciones (o los llamados métodos) suficientes para procesar estos datos necesarios en el programa.

Para comenzar a componer un programa orientado a objetos, es necesario dedicar bastante tiempo a identificar y clasificar los objetos necesarios para que el sistema de software resuelva el problema.

Un objeto puede denominarse distinguible independientemente. modelo de software, como un sistema de modelos de objetos, conceptos y relaciones entre ellos con su comportamiento característico en el tiempo y formas posibles cambios que juegan un papel funcional importante en la solución tarea específica programación.

vamos a dar signos generales objetos.

El objeto es reconocible, es decir. tiene algunos límites, quizás no claramente definidos.

Un objeto se caracteriza por un conjunto de posibles estados en los que reside en determinados intervalos de tiempo. Los estados se reemplazan entre sí durante toda la existencia de un objeto.

Un objeto exhibe sus propiedades cuando interactúa con otros objetos. Esta propiedad a veces se denomina comportamiento de un objeto.

El objeto es único, es decir. Tiene propiedades que le permiten distinguirse de otros objetos.

Un objeto tiene un determinado marco de ciclo de vida. Nace, funciona, cambia de estado tras estado y “muere”. Esta propiedad está asociada a la existencia en el programa de un marco claramente definido para el funcionamiento del objeto. Los objetos del programa local tienen la menor "vida", la máxima - objetos globales, que aparece inmediatamente después de que se inicia el programa y desaparece inmediatamente antes de su finalización.

Las propiedades enumeradas de los objetos asignados al resolver un problema específico corresponden casi por completo a las funciones futuras de los objetos en el programa. El funcionamiento de un objeto generalmente comienza con la asignación de RAM de la computadora y el establecimiento de un cierto estado inicial (valores iniciales durante la inicialización). Durante la operación posterior del programa, el área de memoria ocupada por el objeto cambia, caracterizando los nuevos estados del objeto que interactúa con otros objetos; Y finalmente, cuando completa su trabajo, el objeto libera la memoria que ocupaba.

Las propiedades de un objeto permiten distinguir el concepto de "objeto" del concepto algo opuesto de "clase".

2. Definición de clase

Objetos con propiedades idénticas y métodos.

Una de las primeras acciones que realiza una persona cuando intenta comprender el mundo que nos rodea, es aplicar algunos forma estructural. Cuando encontramos un objeto desconocido, intentamos encajarlo en nuestra estructura existente: en otras palabras, clasificarlo. La mayoría de las personas están familiarizadas con al menos algunas estructuras o jerarquías de clasificación.

El uso de una jerarquía de clases introduce la necesidad de abstracción. Las clases se vuelven más abstractas a medida que se asciende en la jerarquía.

Los lenguajes orientados a objetos utilizan el mismo enfoque. Las jerarquías suelen comenzar con unas pocas clases abstractas. Cada nueva clase se representa como una subclase de una clase existente (llamada superclase). Hereda datos y métodos de clases superiores en la jerarquía. Sólo se deben definir e implementar datos y métodos que sean nuevos para esta clase.

Una clase es un concepto abstracto, comparable al concepto de categoría en su sentido ordinario.

A partir de determinadas propiedades de cualquier elemento de una determinada categoría, se puede establecer que pertenece a ella. La categoría en sí está determinada. propiedades generales, que tienen todas las instancias de esta categoría.

Esto se puede ilustrar con un ejemplo. instrumentos musicales. Los instrumentos musicales se dividen en las siguientes categorías: viento, percusión y cuerdas.

Todas estas categorías pertenecen a la categoría de instrumentos musicales. A su vez, dentro de la categoría de instrumentos se incluye la categoría de instrumentos musicales. En la Fig. 1 esta estructura de categorías se representa gráficamente en forma de árbol.

Todos los objetos de la misma clase se caracterizan por el mismo conjunto de atributos. Sin embargo, la agrupación de objetos en clases no está determinada por conjuntos de atributos, sino por la semántica. Así, por ejemplo, los objetos establo y caballo pueden tener los mismos atributos: precio y edad. Además, pueden pertenecer a la misma clase si en el problema se los considera simplemente como un producto, o como diferentes clases, que es más natural.

Figura 2.1 Figura 2.2

2.1.Atributos de las clases

Entre los atributos se distingue entre atributos permanentes (constantes) y atributos variables. Los atributos constantes caracterizan un objeto en su clase (por ejemplo, número de cuenta, categoría, nombre de la persona, etc.). Los valores actuales de los atributos variables caracterizan el estado actual del objeto (por ejemplo, saldo de cuenta, edad de la persona, etc.); Al cambiar los valores de estos atributos, cambiamos el estado del objeto.

Cabe señalar que cuando hablamos de objetos y sus clases, no nos referimos a ningún lenguaje de programación orientado a objetos. Esto, en particular, se expresa en el hecho de que en esta etapa del desarrollo de un sistema de software, solo se deben considerar aquellos atributos que en realidad tienen sentido (todos los atributos de los objetos de la clase de cuenta - Figura 2.1 - tienen esta propiedad).

Los atributos están asociados con características de la implementación general. Por ejemplo, si sabe que utilizará una base de datos en la que cada objeto tiene un identificador único, no debe incluir este identificador entre los atributos del objeto en esta etapa. El hecho es que al introducir tales atributos, limitamos las posibilidades de implementar el sistema. Por lo tanto, al introducir un identificador de objeto único en la base de datos como atributo, desde el comienzo del diseño nos negamos a utilizar DBMS que no admitan dicho identificador.

2.2.Operación

Una operación es una función (o transformación) que se puede aplicar a objetos de una clase determinada. Ejemplos de operaciones: verificar, eliminar, colocar (para objetos de la clase de cuenta), abrir, leer, cerrar (para objetos de la clase de archivo - Figura 3.1), etc.

Fig3.1

Todos los objetos de una clase determinada utilizan la misma instancia de cada operación (es decir, aumentar el número de objetos de una determinada clase no aumenta la cantidad de objetos cargados). código de programa). El objeto desde el que se llama la operación se le pasa como argumento implícito (parámetro).

En términos generales, la misma operación se puede aplicar a objetos de diferentes clases: dicha operación se llama polimórfica porque puede tener diferentes formas para diferentes clases. Por ejemplo, para objetos de las clases vector y número_complejo, puede definir la operación +; esta operación será polimórfica, ya que la suma de vectores y la suma números complejos, en general, operaciones diferentes.

Cada operación tiene un método correspondiente: la implementación de esta operación para objetos de una clase determinada. Por tanto, una operación es una especificación de un método, un método es una implementación de una operación. Por ejemplo, en la clase de archivo se puede definir la operación de impresión. Esta operación se puede implementar diferentes metodos: (a) imprimir archivo binario; (b) sello archivo de texto etc. Lógicamente, estos métodos realizan la misma operación, aunque están implementados mediante diferentes fragmentos de código.

Cada operación tiene un argumento implícito: el objeto al que se aplica. Además, la operación puede tener otros argumentos (parámetros). Estos argumentos adicionales parametrizan la operación, pero no están asociados con la elección del método. Un método está asociado sólo con una clase y un objeto (algunos lenguajes orientados a objetos, como C++, permiten la misma operación con diferentes numeros argumentos, y utilizando uno u otro número de argumentos, prácticamente elegimos uno de los métodos asociados con dicha operación; en la etapa de diseño preliminar del sistema, es más conveniente considerar estas operaciones como diferentes, dándoles diferentes nombres, para no complicar el diseño).

Una operación (y los métodos que la implementan) se define por su firma, que incluye, además del nombre de la operación, los tipos (clases) de todos sus argumentos y el tipo (clase) del resultado (valor de retorno). Todos los métodos que implementan una operación deben tener la misma firma que la operación que implementan.

Las operaciones se enumeran en la parte inferior del rectángulo (Figura 3.1) que describe la clase. Cada operación debe estar representada por su propia firma, sin embargo, en las primeras etapas del diseño, puede limitarse a especificar el nombre de la operación, aplazando definición completa firmas para el final de la fase del ciclo de vida considerada (o incluso para las fases posteriores). EN lenguaje grafico En la tecnología OMT, el tipo de cualquier objeto de datos se indica después del nombre de este objeto después de dos puntos (como en Pascal).

Al modelar un sistema, es útil distinguir entre operaciones que tienen efectos secundarios (estos efectos se expresan en cambiar los valores de los atributos de un objeto, es decir, cambiar su estado) y operaciones que producen el valor requerido sin cambiar. el estado del objeto. Estos transacciones recientes se llaman solicitudes.

Solo se puede acceder a los valores de algunos atributos de objeto mediante operaciones en ese objeto. Estos atributos se denominan privados.. La Figura 2.3 muestra atributos privados para objetos de la clase de cuenta. Los valores de los atributos privados de un objeto se pueden encontrar fuera del objeto sólo si se definen consultas apropiadas entre las operaciones de ese objeto. De manera similar, es posible definir operaciones cerradas (auxiliares) en un objeto, pero en las primeras etapas de diseño esto generalmente no se hace, ya que la identificación de operaciones cerradas está asociada principalmente con la implementación del sistema.

Figura 3.2 Atributos y operaciones públicas y privadas

Las consultas sin argumentos (excepto el argumento implícito: el objeto al que se aplica la operación) pueden considerarse atributos derivados. Los valores de los atributos derivados dependen de los valores de los atributos primarios. Ésta es su diferencia con los atributos principales, cuyos valores son independientes. En consecuencia, los valores de los atributos primarios de un objeto determinan tanto su estado como los valores de sus atributos derivados. Entonces, por ejemplo, el largo, ancho y alto de una habitación son sus atributos principales, y el área y la capacidad cúbica son atributos derivados; Se necesita un atributo como la capacidad cúbica para no calcular la capacidad cúbica de la habitación cada vez que se necesita su valor.

La elección de los atributos principales de los objetos es arbitraria, pero los atributos principales no deben incluir aquellos atributos cuyos valores están determinados por los valores de otros atributos, de modo que en realidad se derivan.

Por lo tanto, para definir una clase, debe especificar el nombre de esa clase y luego enumerar sus atributos y operaciones (o métodos). Descripción completa El objeto en el lenguaje gráfico OMT tiene la forma que se muestra en la Figura 3.3. Sin embargo, a veces es conveniente utilizar una descripción abreviada de una clase, cuando en el rectángulo que representa esta clase solo se indica el nombre de la clase. Así, la Figura 2.5 muestra abreviaturas de designaciones de clases para nuestro ejemplo principal: el sistema de servicio al cliente de un consorcio bancario.

Arroz. 3.3. Representación completa de objetos en OMT

Arroz. 2.5. Posibles clases para el sistema AMT (bancario)

2.3. Dependencias entre clases y objetos.

Cada objeto está asociado con una estructura de datos, cuyos campos son los atributos de este objeto y punteros a funciones (fragmentos de código) que implementan las operaciones de este objeto (tenga en cuenta que los punteros de función, como resultado de la optimización del código, generalmente se reemplazan mediante llamadas a estas funciones). Por tanto, un objeto es alguna estructura de datos cuyo tipo corresponde a la clase de este objeto.

Se pueden establecer dependencias de datos entre objetos. Estas dependencias expresan conexiones o relaciones entre clases de objetos específicos. En la Figura 3.6 se muestran ejemplos de dichas dependencias (las dos primeras dependencias son binarias, la tercera dependencia es trenaria). La dependencia se representa mediante una línea que conecta las clases, encima de la cual está escrito el nombre de esta dependencia, o se indican los roles de los objetos (clases) en esta dependencia (indicar los roles es lo más manera conveniente identificación de dependencia).

Arroz. 3.6. Dependencias entre clases

Las dependencias entre clases son bidireccionales: todas las clases de la dependencia tienen los mismos derechos. Esto es cierto incluso en los casos en los que el nombre de la dependencia parece introducir dirección en esa dependencia. Así, en el primer ejemplo de la Figura 3.6, el nombre de la dependencia “tiene capital” sugiere que la dependencia se dirige de la clase rural a la clase urbana (la naturaleza bidireccional de la dependencia parece haber desaparecido); pero hay que tener en cuenta que esta dependencia es bidireccional en el sentido de que al mismo tiempo existe una dependencia inversa que es el capital. Exactamente de la misma manera, en el segundo ejemplo de la Figura 3.6, se puede considerar el par de dependencias de propiedad propia. Estos malentendidos se pueden evitar si las dependencias se identifican no por nombres, sino por los nombres de los roles de las clases que componen la dependencia.

En los lenguajes de programación, las dependencias entre clases (objetos) generalmente se implementan mediante enlaces (punteros) de una clase (objeto) a otra. Representar dependencias mediante referencias revela el hecho de que una dependencia es una propiedad de un par de clases y no de cualquiera de ellas, es decir, La adicción es una relación. Tenga en cuenta que aunque las dependencias entre objetos son bidireccionales, no es necesario implementarlas como bidireccionales en los programas, dejando referencias solo en aquellas clases donde sea necesario para el programa.

En la Figura 3.7 se muestran más ejemplos de dependencias entre clases. El primer ejemplo muestra la relación entre un cliente bancario y sus cuentas. Un cliente de un banco puede tener varias cuentas en este banco al mismo tiempo o no tener ninguna cuenta (cuando se convierte en cliente del banco por primera vez). Por lo tanto, es necesario representar la relación entre el cliente y varias cuentas, lo cual se hace en la Figura 3.7. El segundo ejemplo muestra la relación entre líneas curvas (específicamente rectas) que se cruzan. Puede considerar 2, 3 o más líneas de este tipo y pueden tener varios puntos de intersección. Finalmente, el tercer ejemplo muestra una dependencia opcional: la computadora puede tener o no un mouse.

Las dependencias entre clases corresponden a dependencias entre objetos de estas clases. La Figura 3.8 muestra las dependencias entre objetos para el primer ejemplo de la Figura 2.6; La Figura 3.9 muestra las dependencias entre objetos para los ejemplos que se muestran en la Figura 3.7.

Arroz. 3.7. Otros ejemplos de dependencias. Designaciones

Arroz. 3.8. Dependencias entre objetos

Tenga en cuenta que al representar dependencias entre objetos, por regla general, conocemos el número de objetos y no necesitamos designaciones como "varios", "dos o más", "no necesariamente".

Al diseñar un sistema, es más conveniente operar no con objetos, sino con clases.

Arroz. 3.9. Dependencias más complejas entre objetos.

El concepto de dependencia se ha transferido a la tecnología de diseño orientada a objetos. sistemas de software de la tecnología de diseño (y modelado) de bases de datos, donde las dependencias se han utilizado durante mucho tiempo. Los lenguajes de programación, por regla general, no admiten una descripción explícita de dependencias. Sin embargo, describir las dependencias es muy útil al desarrollar sistemas de software. La tecnología OMT utiliza dependencias para interpretar diagramas que describen un sistema.

Conclusión

Los objetos del programa funcionan como un equipo bien coordinado. programas independientes, quienes saben por sí mismos cuándo, dependiendo de la situación actual, deben comenzar a trabajar, cuándo suspenderlo temporalmente y, finalmente, cuándo abandonar por completo el equipo del programa, sin dejar más recuerdo de sí mismos que los necesarios resultados útiles del trabajo. Como regla general, cada objeto, al comenzar su trabajo, recibe pedidos de Sistema operativo RAM para sus datos, y al finalizar el trabajo, devuelve esta memoria al sistema. Esto optimiza la cantidad de memoria que ocupa todo el programa durante su funcionamiento.

Para que los objetos conozcan claramente su lugar y poderes en un solo equipo y no realicen el mismo trabajo, están sujetos a una clasificación especial, cuyo resultado es la identificación de clases de objetos. Si dos clases tienen propiedades comunes, entonces debe haber una clase más general para ellas que tenga sólo aquellas propiedades que son comunes a estos dos objetos. En este caso, los objetos de clases con propiedades comunes sólo necesitan preocuparse por realizar las funciones asociadas con sus distintas propiedades. La parte general puede ser realizada por un objeto de una clase más general.

Analizamos las definiciones de clase, objeto, atributos, operaciones, los componentes principales del enfoque orientado a objetos.
Se puede dividir en cuatro etapas.

La primera etapa es identificar abstracciones. Aislar abstracciones significa analizar el área temática para la cual se está compilando el programa para determinar los objetos principales del área temática, sus propiedades, las relaciones entre objetos, así como las posibles operaciones sobre los objetos y sus componentes.

La segunda etapa consiste en escribir objetos y sintetizar tipos abstractos datos. La etapa implica definir nuevos tipos de datos derivados y conjuntos de funciones u operaciones específicas aplicadas a estos tipos de datos de tal manera que se excluya la posibilidad de mezclar o intercambiar diferentes tipos.

La tercera etapa es el objeto.descomposición como la selección de subtipos o subobjetos y sus componentes para cada tipo de objeto.

La cuarta etapa representa la jerarquización compositiva de los objetos como la identificación de relaciones genéricas y compositivas sobre los objetos.

Como resultado del enfoque orientado a objetos para el diseño de programas, el proceso de desarrollo del programa se convierte en un proceso evolutivo.programación, en la que realizar cambios y adiciones al programa no requiere una revisión radical de sus algoritmos constituyentes. El método evolutivo de programación se basa en preservar la integridad de los objetos del programa, es decir. Los cambios en el programa no deberían afectar. organización interna objetos existentes en él.

Propiedad importante Los lenguajes orientados a objetos son la capacidad de desarrollar en ellos programas que funcionen en sistemas con complejos procesos informáticos paralelos inherentes a medios tecnicos tecnología informática. Esta propiedad se basa en el concepto de objetos activos e inactivos durante el funcionamiento del programa. La actividad simultánea de varios objetos se hace posible debido a su tipificación estricta y su carácter cerrado a los cambios de otros objetos.