Diseño conceptual. Open Library: una biblioteca abierta de información educativa. Triz y el diseño conceptual.

El requisito previo para la creación de su metodología fue el diagnóstico de S.P. Nikanorov de la situación actual en el desarrollo de las organizaciones: hay una acumulación de decisiones no sistémicas, el pensamiento situacional momentáneo se está extendiendo por todas partes, lo que conduce al llamado fenómeno de plegamiento. el proceso de aparición arbitraria de algo bajo la influencia de muchos factores que aparecen espontáneamente. Si algo no funciona eficazmente, suelen decir: "Simplemente sucedió, nadie tiene la culpa". La consecuencia del plegamiento son áreas de la vida incontrolables y problemas emergentes que requieren acción para resolverlos.
¿Quién tiene problemas? Sólo pueden ser entre sujetos, es decir, entre aquellos que tienen capacidades e intereses. El problema para el sujeto es la discrepancia entre intereses y capacidades. Los sujetos pueden percibir lo que está sucediendo aproximadamente de la misma manera, pero lo atribuyen a sus intereses y capacidades, que no ascienden más. un cierto nivel. Por tanto, lo que está sucediendo no es percibido por ellos como un único problema integral, que conduce a soluciones no sistémicas.
¿Qué enfoques existen para resolver estos problemas? Algunos sujetos esperan abordarlos utilizando un enfoque orientado a problemas, que examina las deficiencias identificadas que impiden que el sujeto alcance sus objetivos. Una forma refinada de este enfoque es el análisis de sistemas, que utiliza la ideología de los sistemas orientados a objetivos. Pero es imposible eliminar el fenómeno del plegado utilizando métodos orientados a problemas, ya que no surgen problemas individuales, sino una maraña de problemas. Y si intentas resolver cualquier problema, la maraña de problemas sólo aumenta y se enreda, como una maraña ordinaria de hilos cuando se arranca un hilo. Es necesario superar la maraña utilizando un enfoque normativo, que se base en el supuesto de la clase deseada de sistemas. Al crear sistemas, este enfoque debe coordinarse con el enfoque orientado a problemas. Es absurdo eliminar las deficiencias de un sistema obsoleto. No debemos resolver los problemas, sino construirlo todo de nuevo, subordinando a esta idea tanto nuestros intereses como nuestras capacidades. Una forma refinada del enfoque normativo son los sistemas con un ideal por el que deben esforzarse.
La desventaja de estos enfoques, que surgieron en los años 60 del siglo XX y son producto de la carrera armamentista, es la falta de ideas sobre el desarrollo, en particular, sobre la transición de una calidad obsoleta a una nueva calidad, que viene determinada por una secuencia de objetivos.
A principios de la década de 1970, mucho antes de que se realizara en amplios círculos desarrolladores de la inutilidad de crear sistemas automatizados basados ​​​​en metodologías tradicionales, S.P. Nikanorov formó un nuevo enfoque metodológico en el que el objeto diseño asistido por computadora No eran sistemas de control automatizados, sino sistemas de gestión organizacional (OMS). Estos sistemas incluyen cualquier organización en la que la producción, gestión, diseño, capacitación y otras actividades se llevaron a cabo utilizando computadoras. sistemas de información. La idea de la necesidad y los problemas del diseño de organizaciones se analiza en el prefacio del libro de S. Young traducido bajo su dirección (en la sección 1).
Sobre la base de este enfoque, en 1978 se publicó un proyecto técnico. sistema automatizado diseño (ASP) SOU. Este
Se suponía que ASP resolvería el problema de garantizar la controlabilidad del proceso de diseño en condiciones de cambios continuos en el entorno interno y ambiental, tanto del sistema que se diseña como del sistema que lo diseña, utilizando métodos matemáticos. modelado conceptualárea temática. Se debía garantizar el control teórico de los procesos del proyecto, desde la formación del plan primario hasta el diseño detallado y la creación de la organización.
La esencia de la metodología. Antes de diseñar directamente un sistema de gestión organizacional, se forma su modelo conceptual matemático general. El proceso de diseño se reduce a especificaciones controladas. modelo general y su posterior interpretación. Esto garantiza la integridad del diseño del sistema, a diferencia de la tecnología tradicional, donde el diseño es una colección de piezas desarrolladas de forma autónoma. Luego se compara el diseño obtenido deductivamente con los requisitos originales. Si se identifican inconsistencias, el modelo conceptual se ajusta y luego se rediseña.
Así, en esta metodología, el proceso de conceptualización matemática es iterativo y no se reduce a una formalización inequívoca del objeto y del proceso de diseño, como ocurre, por ejemplo, cuando se diseña un complejo de calor y energía realizado por el Sistema MAVR.
En el proyecto técnico desarrollado de la ASP SOU, los métodos de modelado y diseño se centraron en un diseño teórico e instrumental-tecnológico lógicamente dirigido y, por lo tanto, controlado. En primer lugar, se aseguró la integridad del espacio de diseño conceptual mediante la formación lógica todas las combinaciones posibles elementos de construcción conceptual utilizando métodos morfológicos y otros. Y la explicación matemática hizo posible operar con construcciones conceptuales independientemente del contenido aplicado y del diseño simbólico.
Las funciones del sistema ASPSOU se muestran en la Tabla 7.1. La teorización de un área temática se basa en identificar problemas, establecer su carácter sistémico y sus posibles soluciones. Al diseñar un sistema de señalización se determina la composición de bases de datos, formularios de documentos, etc.
Tabla 7.1 Funciones Salida Entrada 1. Definición e implementación del concepto de teorización del área temática
Interpretación operativa de esquemas teóricos. Definición de procedimientos de control con sus entradas y salidas.
Diseño de una implementación simbólica del SOU y referencia espacio-temporal.
Documentación del proyecto SOU 1. Modelo (teoría) del área temática
Diseño de un sistema de gestión organizacional 1. Metamodelos,
describir los conceptos de sistemas de gestión organizacional y sus elementos
Metamodelos de teorías formalizadas.
Para implementar esta metodología se desarrolló un conjunto de esquemas teóricos, denominados constructos, con los que se formó, mediante métodos lógicos, una teoría del área temática y un modelo del objeto de diseño. El desarrollo de constructos y la posterior síntesis de teorías específicas con la formación controlada de conceptos derivados se llevó a cabo utilizando el aparato matemático de la teoría de estructuras de Bourbaki. fueron creados varias tecnologías operar con constructos, permitiendo sobre su base formar esquemas conceptuales complejos y al mismo tiempo fácilmente modificables.
De la descripción de la estructura funcional se desprende claramente que, a diferencia del sistema de programación conceptual PRIZ (ver Sección 2), las teorías del área temática y los modelos del objeto de diseño no son la entrada, sino la salida del sistema ASP SOU. . Y sólo entonces los proyectos SOU se forman como resultado derivado de la inferencia lógica sobre los modelos construidos del área temática y la posterior interpretación de estructuras matemáticas abstractas. La entrada al proceso de diseño se forma utilizando esquemas metamatemáticos abstractos (construcciones) creados previamente, metamodelos que describen los conceptos de SOU y sus elementos, y metamodelos que describen las teorías formalizadas existentes necesarias para modelar la SOU. Estas incluyen teorías de sistemas técnicos, teorías de sistemas de producción, teorías de sistemas dirigidos a objetivos, etc. Lo que también es nuevo aquí es el uso de una representación axiomática de las teorías.
Estructura funcional de la ASP SOU
La universalidad de esta metodología está predeterminada por el metamodelo general generado del sistema diseñado utilizando
construcciones que están en la memoria del sistema y las posibilidades de su especificación durante el diseño. Si, al interpretar un metamodelo concreto utilizando los conceptos del área temática cubierta, SOU y sus elementos, se revela su insuficiencia, entonces se seleccionan otros métodos de concretización o se ajusta el modelo conceptual general.
Los modelos matemáticos de conceptos se forman utilizando varias teorías como la teoría de estructuras, teoría de conjuntos, teoría categórica de sistemas, etc., en diferentes formas simbólicas - textos, tablas, fórmulas, gráficos, etc., en diferentes idiomas, fuentes y con diferente colocación en diversos medios. Esto se puede expresar utilizando un esquema teórico propuesto en los años 70 por S.P. Nikanorov, llamado “logosinotopotech”. Identificó una entidad lógica (“log”), que representa su signo (“syn”) y la ubicación del signo (“top”) en el medio (“tech”). Lo principal en este esquema era la relación semántica: "log" revela el significado de la representación del signo "syn".
En este enfoque, el objeto de diseño es y estructura funcional organización y su proceso de diseño. La metodología incluye etapas de diseño deductivo e inductivo. La etapa deductiva se lleva a cabo con la ayuda de un metasistema previamente desarrollado y almacenado de descripciones axiomáticas conceptuales de las áreas necesarias de conocimiento en diferentes formas matemáticas: constructos de teoría de conjuntos, categóricos y de teoría de sistemas en las escalas de conjuntos de N. Bourbaki. Luego, para los metamodelos generados del sistema, se realiza una elección de métodos y, en última instancia, se realiza una elección de tecnologías utilizando una base de diferentes teorías, modelos, métodos y herramientas.
La etapa inductiva comienza con el seguimiento de la adecuación de los proyectos formados y el posterior ajuste iterativo de los esquemas teóricos iniciales.
La aplicabilidad de la metodología considerada para el diseño de organizaciones se limita a apuntar a especialistas altamente calificados que posean las herramientas para crear y utilizar construcciones matemáticas, que ha sido llevada a cabo durante las últimas tres décadas por un equipo científico encabezado por S.P. Nikánorov.
Actualmente, existen varios cientos de construcciones y un conjunto de métodos para operar con ellas. Un equipo relativamente pequeño de especialistas desarrolló información y herramientas de software para respaldar automáticamente la formación de metamodelos matemáticos de áreas temáticas utilizando una base acumulada de constructos. Se creó un sistema automatizado que proporcionaba un modo de consulta y ejecución de operaciones de síntesis, generación, visualización, etc., analizadores sintácticos y semánticos, así como un intérprete lingüístico de tipos de estructuras. El mayor desarrollo de las herramientas se centró en apoyar el proceso de diseño de procedimientos organizacionales y formularios de documentos.
Desafortunadamente, cuando apareció no se desarrolló un diseño tecnológico detallado y un sistema instrumental completo para implementar esta metodología. Para obtener un resultado industrial, fue necesario involucrar a poderosas organizaciones especializadas en el desarrollo de software de información, lo que requirió serias apoyo del gobierno. Érase una vez el académico V.M. Glushkov, director del Instituto de Cibernética de Kiev, que dijo que la creación de un sistema automatizado de alcance nacional (OGAS) debe financiarse del mismo modo que los programas espaciales o la industria nuclear. Pero, lamentablemente, esto no sucedió.
Considerando esta metodología desde una perspectiva moderna, está claro que no se prestó suficiente atención al modelado y desarrollo directo y específico de las organizaciones existentes en el marco de las teorías de la producción y los sistemas económicos. Se centró en el desarrollo de nuevos sistemas, que correspondían a la orientación que existía en ese momento sobre la creación de sistemas automatizados de producción, diseño y gestión.
Aunque formalmente era necesario realizar un examen y análisis preliminar de los sistemas existentes, de acuerdo con la documentación reglamentaria disponible, e incluso se desarrollaron métodos detallados para el examen de diagnóstico y el modelado de organizaciones, en la práctica esto rara vez se llevó a cabo. A falta de herramientas adecuadas esta etapa requirió un enorme esfuerzo y tiempo, y el resultado del trabajo de los diseñadores se tuvo en cuenta de acuerdo con el proyecto presentado a la comisión estatal nuevo sistema y su implementación experimental.
Con el método elegido de formación deductiva de proyectos, resulta difícil hacer la transición a la diversidad existente de contenidos de los procesos reales, en los que se lleva a cabo una interpretación del modelo, cuando los elementos del modelo reflejan elementos específicos de los sistemas de gestión organizacional, denotados por los términos de el campo original del conocimiento. En la interpretación del metamodelo, a los términos de las construcciones teóricas se les asignan las llamadas variables lingüísticas. Pero como llegar a elementos específicos sistema de gestión organizacional, si su modelo inicial no ha sido construido previamente? Y como moldear para ella modelo matemático con un conjunto dado de ciertas restricciones y función objetivo, adecuado a la realidad?
Dichos modelos tuvieron que crearse durante el desarrollo de organizaciones existentes y hubo que acumular modelos prototipo para su uso en el diseño de nuevos sistemas. Pero debemos recordar que el uso de estos modelos en forma visual sólo fue posible después de la aparición de computadoras con alta velocidad y gran memoria, así como herramientas, asegurando la formación de tales modelos. Sin tales modelos, es imposible realizar una comparación operativa de los resultados teóricos con los requisitos especificados en el campo de conocimiento original y determinar la idoneidad de los esquemas abstractos utilizados.
Por otro lado, si existe un modelo significativo específico construido en términos del campo de conocimiento original, y el sistema instrumental puede procesar lógicamente conceptos no matemáticos, entonces es necesario justificar la viabilidad de utilizar modelos conceptuales matemáticos en condiciones de utilizando redes de computadoras con gran memoria y velocidad.
Al utilizar la metodología considerada, se debe tener en cuenta que, si bien reduce la diversidad y mantiene el desarrollo del sistema dentro de ciertos límites teóricos, el uso de constructos simultáneamente tosca el área temática, limitando las posibilidades de modelado conceptual de los profesionales. Cuando se crea una construcción, se considera e idealiza algún aspecto de la esencia. Una vez creado, un constructo puede tener muchas encarnaciones materiales y simbólicas, pero al mismo tiempo refleja solo un análogo matemático de algún lado de la esencia, y no el lado sustantivo de la esencia misma, que puede ser percibido adecuadamente por un profesional en este campo. Al mismo tiempo, la naturaleza del conocimiento en las áreas temáticas es a menudo tal que las frases con las que se comunican los profesionales son sólo un indicio de las imágenes de la entidad real que surgen en ellos durante la formación y como resultado de la adquisición de experiencia. Estas imágenes se activan cuando una frase se percibe en la mente de un especialista, pero para transmitir el significado de las frases a especialistas de otros campos del conocimiento, las imágenes correspondientes requieren decodificar pistas.
El problema también es garantizar el control teórico del proceso de creación de constructos, en particular, justificar la elección de los aspectos de la esencia que subyacen al desarrollo de los constructos matemáticos y la corrección de su implementación. Los constructos matemáticos utilizados deben asegurar la integración de métodos y herramientas disponibles en diferentes áreas temáticas, desempeñando la función de su superestructura teórica. Considerando la enorme escala y complejidad de las áreas de conocimiento que un desarrollador moderno necesita cubrir, estos constructos también pueden desempeñar una función epistemológica.
Al analizar este enfoque se observó que está enfocado a brindar directamente las propiedades deseadas al momento de diseñar sistemas. Pero para su implementación es necesario acumular los constructos necesarios que brinden tales oportunidades, probar los métodos necesarios de síntesis, concretización e interpretación y sus software, llevándolo a un nivel industrial. El uso limitado de este enfoque puede deberse a los problemas de transición de los constructos generales a la diversidad conceptual existente del campo de conocimiento inicial, así como al hecho de que solo puede ser implementado de manera efectiva por especialistas que sepan trabajar con constructos. .
Se proporciona una bibliografía completa de publicaciones sobre análisis y diseño de conceptos para el período de 1967 a 2003. Presenta 742 publicaciones, agrupadas alfabéticamente por autores, por año de publicación y por tema. El índice de autores cubre 189 autores y el índice temático cubre 83 títulos.

La tarea del diseño conceptual es determinar las necesidades de información de la "empresa", aquellos procesos y datos que son necesarios para satisfacer estas necesidades. El proceso de diseño conceptual comienza con un estudio de las actividades de la "empresa", es decir del análisis de dominio. En primer lugar, se determinan las metas y objetivos de la empresa, se analizan los procesos (planificación, gestión, control) que aseguran el logro de estas metas y el cumplimiento de las tareas asignadas. Luego, los procesos se dividen en procesos de nivel inferior hasta que la descomposición da como resultado un nivel de aplicación que se puede ejecutar sin más particiones. A continuación, se determinan las necesidades de información de cada aplicación y se definen los requisitos de datos que, en esencia, definen las vistas locales analizadas anteriormente. El proceso posterior de combinar estas representaciones locales, eliminando las contradicciones emergentes, tiene como objetivo crear una única representación integral de la base de datos, denominada, como se mencionó anteriormente, representación conceptual. Desafortunadamente, cabe señalar que el diseño de bases de datos sigue siendo un ejercicio muy subjetivo, ya que no existen métodos verdaderamente rigurosos para resolver este problema.

Un diagrama conceptual describe una idea general en términos de algún resumen.modelos de datos .

2. modelo de datos

Cualquier modelo de datos contiene tres componentes:

Descripción de la estructura de datos. , aquellos. Descripción de los objetos sobre los que se construye la base de datos.

Restricciones de integridad , es decir. un conjunto de reglas que limitan el conjunto de instancias de estos objetos que se permiten en la base de datos.

Conjunto de operaciones válidas , es decir. un conjunto de operadores que se utilizan para procesar instancias de objetos.

El modelo de datos asume, como mínimo, la presencia de un lenguaje de definición de datos (DDL) para describir la estructura y un lenguaje de manipulación de datos (DML), incluidas operaciones para recuperar y modificar datos, así como la presencia de un mecanismo para mantener. conformidad de los datos con el área temática en base a reglas formalmente descritas.

Peter Chen propuso un enfoque popular para el modelado de datos en su trabajo "El modelo entidad-relación: hacia una visión unificada de los datos". Este enfoque se basa en el modelo entidad-relación o modelo ER, que se analiza en esta conferencia.

El modelo ER se basa en información semántica importante sobre el mundo real y pretende lógico presentación de datos.

3.El modelo “entidad-relación”. Conceptos semánticos

Indiquemos los conceptos semánticos (elementos constructivos) utilizados en este modelo.

Entidades (usaremos el término más familiar – Objetos ) se dividen encorrecto (fuerte) Ydébil . DébilSe llama a un objeto que depende de algún otro objeto, es decir no puede existir si este otro objeto no existe.Un objeto correcto es un objeto que no es débil. Por ejemplo, en una base de datos de una empresa que almacena datos sobre las preferencias de los clientes, el objeto Preferencias es débil porque Una instancia de este objeto correspondiente a un cliente en particular no puede estar en la base de datos a menos que exista una instancia correspondiente del objeto Cliente. En particular, si se elimina esta instancia del objeto "Cliente", también se deben eliminar todas las instancias del objeto "Preferencias" que dependen de él.

Puede haber casos en que algún objetoA es un tipo especial de otro objetoEN . Entonces dicen queA essubtipo EN (o "A HayEN ") oEN esgeneralización A . Por ejemplo, en la base de datos de Aerolíneas hay un objeto llamado Empleados. Para indicar qué empleado es piloto, puede definir el objeto "Piloto" en la base de datos como un subtipo del objeto "Empleado". Los pilotos tienen automáticamente todas las propiedades de los empleados, pero la afirmación inversa no es cierta (por ejemplo, para los pilotos, se puede definir adicionalmente la propiedad "Tipo de aeronave en la que el piloto es más competente", lo cual no se aplica a todos empleados). Asimismo, los pilotos participan automáticamente en todas las comunicaciones (ver más abajo) en las que participan los empleados. Se dice que tales propiedades y conexiones son son heredados subtipo del supertipo.

Un subtipo, a su vez, puede ser un supertipo para objetos de subtipo del siguiente nivel, que a su vez lo son para el siguiente, etc., formando así una jerarquía de tipos para un objeto determinado. Un ejemplo de tal jerarquía se muestra en la Fig. 1.

Arroz. 1. Ejemplo de jerarquía de objetos

La jerarquía de tipos no debe confundirse con la jerarquía de datos. La Figura 1 no implica en absoluto que un empleado pueda tener varios programadores subordinados a él; al contrario, para una instancia del objeto "Empleado" hay; máximo una instancia del objeto Programador que representa al mismo empleado en el rol de programador.

Atributos y su clasificación.

Déjanos recordarte , que un atributo es una propiedad de un objeto o relación, que se caracteriza por un nombre y un conjunto de valores válidos.

Atributos se dividen ensimple Ycompuesto. Un atributo simple no se puede dividir en elementos independientes más pequeños (dentro del alcance del modelo de datos que se utiliza). Un atributo compuesto consta de varios elementos que existen independientemente (por ejemplo, la propiedad compuesta “nombre del empleado” puede consistir en propiedades simples

Atributos "nombre", "patronímico" y "apellido").también se dividen en – Yinequívoco . polisemántico inequívoco El atributo contiene solo un valor para cada instancia de objeto.. cierto tipo De valor múltiple un atributo puede contener múltiples valores para cada instancia de un objeto de un determinado tipo

. Por ejemplo, el nombre de un departamento o sucursal de una empresa es un atributo de un solo valor y el número de teléfono de un departamento generalmente tiene varios valores (puede tener varios números).Otra división de atributos es en Ybásico derivados. Base un atributo es aquel cuyo valor no depende de los valores de otros atributos

de este objetou otros. Un atributo derivado es aquel cuyo valor depende de los valores de algún conjunto de otros atributos. El atributo es.

llave

, único si identifica de forma única cada instancia de un objeto de un conjunto determinado Conexiones y sus características.Conexiones se establecen entre objetos llamadosparticipantes , y el número de participantes en esta conexión se llamagrado esta conexión. La comunicación puede serlleno oparcial . DejarR es una relación que contiene un objetoR miparcial como participante. Entonces, si cada instancia de un objetoR está en al menos una instancia de la conexiónparcial , luego participación Por ejemplo, si cada producto debe ser suministrado por al menos un proveedor, entonces la participación de los bienes en la relación entre bienes y proveedores es completa. Pero si tal situación es permisible cuando un determinado producto no es suministrado por ningún proveedor, entonces la participación de los bienes en la conexión es parcial.

Analicemos varias características generales importantes de las conexiones:

Se puede definir una relación en más de dos objetos. Por ejemplo, la conexión entre los objetos “Departamento” - “Especialización” - “Asignatura” - “Tipo de prueba” determina la lista de pruebas (exámenes, pruebas, trabajos de curso, etc.) que debe aprobar un estudiante que estudia en un cierta especialización en un departamento específico (por ejemplo, “tiempo completo”). Esta conexión se define, en particular, sobre cuatro entidades.

Puede haber múltiples relaciones definidas en los mismos conjuntos de objetos.. Por ejemplo, las relaciones "Trabaja en" y "Administra" se definen en conjuntos de objetos coincidentes ("Proyecto", "Empleado").

Se puede establecer una relación entre diferentes instancias del mismo objeto.Esta conexión se llama

recursivo.La comunicación puede determinar dependencia de la existencia(dependencia de existencia) de un objeto de otro

. Por ejemplo, una relación Subordinada indica que la existencia de una instancia de un objeto en el conjunto Subordinado depende de la presencia de una instancia de algún objeto en el conjunto de objetos Empleado. La principal actividad de Method Company desde el momento de su fundación hasta la actualidad es el desarrollo de inventivas. programas de computadora basado en métodos de diseño conceptual

sistemas técnicos. Diseño conceptual es un tipo separado de actividad de proyecto. Su resultado son variantes de los conceptos de lo proyectado. sistema tecnico

(TS) tanto en su conjunto como en sus partes individuales. El concepto de vehículo tiene varias formas
representaciones que difieren en el nivel de elaboración (especificidad). Este:

Diagrama funcional, que indica un conjunto de elementos del vehículo que realizan una función técnica particular y el método de su interacción. Principio de funcionamiento , que determina la relación entre los fenómenos físicos (químicos, etc.) que ocurren en el vehículo en varias etapas

su ciclo de vida. Principio de cambio , indicando cómo cambiar materiales, diseño, modos de funcionamiento e interacción del dispositivo con ambiente

para mejorar su desempeño. Diagrama estructural , que determina la composición del vehículo, la posición relativa y la relación entre sus elementos, sus características, materiales utilizados, proporción óptima de parámetros de elementos y otras características esenciales. Por lo general, para abreviar la presentación, el diagrama de diseño de un vehículo se presenta en la forma fórmula distintiva. Enumera sólo aquellas características de diseño que distinguen el vehículo diseñado de su prototipo.

La mayor parte de los problemas de diseño conceptual deben resolverse en las primeras etapas del desarrollo de un vehículo: durante el desarrollo de un proyecto conceptual y el diseño preliminar. En otras palabras, cuando se determina la apariencia del futuro producto. Sin embargo, en el futuro, en las etapas de diseño detallado, pruebas y lanzamiento de producción, los desarrolladores se enfrentarán a problemas técnicos complejos. Su eliminación también requiere métodos de diseño conceptual.

El lugar y alcance del diseño conceptual como procedimiento de búsqueda independiente se explica en el siguiente diagrama.

El diseño conceptual es el componente más importante del proceso de creación de un nuevo producto. En última instancia, es la cantidad de conceptos desarrollados para el futuro producto lo que lo determina. novedad Y calidad, y, por tanto, su competitividad y volumen de ventas.

La aplicación práctica de los métodos de diseño conceptual ha demostrado que son indispensables para resolver problemas como:

• desarrollo de nuevos dispositivos y tecnologías;
• mejorar la calidad y reducir los costos de producción;
• previsión para el desarrollo de un campo tecnológico específico;
• obtener prioridad en un campo técnico determinado;
• gestión del conocimiento y propiedad intelectual empresas.

Invención y diseño conceptual.

La invención y el diseño conceptual son actividades relacionadas y se diferencian principalmente en sus objetivos.

La invención es una actividad de iniciativa individual. El objetivo del inventor es crear una invención, es decir. solución técnica que tiene novedad mundial. La invención, como tipo de actividad humana, es similar al arte. Por lo tanto, muy a menudo la creación de una invención implica elemento de azar. Muchos inventos maravillosos aparecen “ni entonces” ni “allí”, como exige la producción real. Esta es una de las principales razones de la dificultad de poner en práctica la invención.

¡La naturaleza aleatoria de la invención puede retrasar el desarrollo de la tecnología no durante años, sino durante milenios! Por ejemplo, los antiguos griegos conocían todos los elementos elementales. dispositivos tecnicos, que Edison utilizó en su fonógrafo para grabar y reproducir sonido. Conocían la capacidad de las cuerdas para vibrar cuando sopla el viento, la vibración de las membranas de los tambores, usaban una palanca para aumentar la fuerza y ​​usaban tablillas recubiertas de cera para escribir palabras. Sin embargo, no pudieron combinar todos estos conocimientos en un solo dispositivo. Por cierto, Edison también debe su invención del fonógrafo a un feliz accidente.

A diferencia de la invención, el diseño conceptual es actividades de producción planificadas. Su objetivo es resolver el problema técnico que se plantea a los desarrolladores en un plazo determinado. En este caso, normalmente la tarea no es encontrar una solución técnica fundamentalmente nueva, es decir, invención.

Si se encuentra una solución técnica fuera de plazo, por regla general es prácticamente imposible implementarla. Usar una solución de este tipo en el proyecto actual es imposible, porque tiempo perdido. En el próximo proyecto de un producto similar, esta solución tampoco suele tener cabida, porque Aparecen nuevas necesidades y nuevas soluciones.

El objetivo del diseño conceptual (garantizar una solución sistemática a un problema técnico) se logra mediante el uso de tecnologías de la información modernas. A diferencia de la invención, que está dominada por la creatividad humana, el diseño conceptual es principalmente una tecnología. es ella quien permite garantizar el resultado deseado en el momento oportuno.

TRIZ y el diseño conceptual

TRIZ, la teoría de la resolución de problemas inventivos, fue desarrollada por G.S. Altshuler. y sus alumnos en la URSS en el período 50-80 del siglo pasado. Esta metodología se está desarrollando con éxito hasta el día de hoy. Los métodos TRIZ son utilizados tanto por inventores individuales como por empresas consultoras en muchos países del mundo.

TRIZ y el diseño conceptual son metodologías relacionadas. Tienen el mismo objetivo: una solución planificada y específica. problemas tecnicos, pero diferentes métodos.

El principal arsenal de TRIZ es métodos heurísticos, que consta de algoritmos especiales, instrucciones, recomendaciones metodológicas, etc., que están enfocados a su uso por parte de humanos. Métodos TRIZ ayuda un inventor para analizar un problema técnico, encontrar una solución y ampliar su alcance.

El uso más amplio de los métodos TRIZ en la práctica de la ingeniería está limitado por la necesidad pre-entrenamiento. Dominar estos métodos al nivel adecuado solo es posible después de una formación prolongada en cursos especiales impartida por un profesor experimentado.

Una respuesta adecuada al problema del aprendizaje fue la creación de programas informáticos que implementen métodos TRIZ. Sin embargo, esto no evita por completo la formación preliminar. Estos programas utilizan la computadora como ayuda. Con su ayuda, el inventor registra principalmente los resultados de la resolución de un problema técnico y también encuentra heurísticas y ejemplos técnicos adecuados. Al trabajar con dichos programas informáticos, el inventor debe realizar él mismo todo el alcance de las operaciones creativas.

Usos del diseño conceptual métodos formales y grande base de conocimientos, que sólo puede implementarse en forma de programas informáticos. El usuario no necesita necesariamente saber qué métodos (algoritmos) se utilizan en estos programas. Todo lo que necesita hacer es indicar un problema técnico, hacer clic en el botón "Resolver" y seleccionar la mejor solución encontrada. Por lo tanto, los métodos de diseño conceptual permiten a cualquier ingeniero resolver problemas técnicos de manera intencionada sin una formación metodológica previa.

A pesar de estas diferencias, los enfoques y el diseño conceptual de TRIZ no se excluyen, sino que se complementan entre sí. Los métodos TRIZ son indispensables cuando se buscan formas de resolver un problema técnico. Ayudan al ingeniero a pasar de un problema técnico complejo a problemas inventivos típicos. Luego se pueden aplicar métodos de diseño conceptual. Actualmente, los programas inventivos basados ​​en métodos de diseño conceptual pueden resolver algunos problemas inventivos de complejidad media. Esto es proporcionado por extensas bases de datos. conocimientos específicos de ingeniería y complejo algoritmos formales, que se utilizan en estos programas.

Además, como muestra nuestra experiencia, mejores resultados Cuando trabajan con programas de invención modernos, los ingenieros que hablan TRIZ lo logran.

A esto hay que sumarle que nunca será posible formalizar por completo todo el proceso de resolución de problemas técnicos. Es obvio que con el tiempo el alcance de los programas informáticos inventivos se ampliará, pero nunca sustituirán por completo a los humanos en esta materia. Y esto no se debe al hecho de que algunos problemas matemáticos aún no se hayan resuelto o que las computadoras existentes no tengan suficiente velocidad y memoria. Sólo hay un problema: ¡el ordenador no inventa porque no quiere!

sistemas técnicos. a veces llamado técnico. Sus principales etapas son:

1) diseño preliminar,

2) diseño preliminar (detallado o técnico-detallado),

3) fabricación, prueba y acabado prototipo sistemas (Fig. 4.3).

Arroz. 4.3. Etapas de diseño conceptual.

La etapa de diseño conceptual comienza con análisis detallado datos primarios y aclaración modelo conceptual datos, después de lo cual se diseña arquitectura del sistema. Al mismo tiempo, se evalúa la posibilidad de utilizar los SI existentes y se selecciona el método adecuado para convertirlos. Después de construir el proyecto, se perfecciona el plan de negocios inicial. Los componentes de salida de esta etapa son un modelo de datos conceptual, un modelo de arquitectura del sistema y un plan de negocios refinado.

Durante las siguientes etapas de diseño se espera un estudio más profundo y detallado de las soluciones desarrolladas en esta etapa. Al mismo tiempo, no se puede descartar la necesidad de realizar cambios significativos. Aunque los documentos reglamentarios actuales prevén la posibilidad de realizar cambios en un proyecto o programa (concepto), por regla general, esto se asocia con pérdidas de recursos financieros, materiales y laborales tanto por parte del "Cliente" como del "Desarrollador". . Estas pérdidas pueden ser bastante significativas si es necesario realizar cambios significativos en las decisiones de diseño iniciales y más tarde surge esta necesidad. Esto implica la especial importancia de esta etapa de diseño para creación exitosa AIS, así como la responsabilidad de los Desarrolladores y el Cliente al realizar el trabajo y acordar el documento final.

En etapa de desarrollo, integración y pruebas, se debe crear una base de datos de pruebas y pruebas. El desarrollo, creación de prototipos y pruebas de bases de datos y aplicaciones se lleva a cabo de acuerdo con el proyecto. Se están depurando las interfaces. sistemas existentes. Describe la configuración versión actual POR. Según los resultados de las pruebas, la base de datos y las aplicaciones se optimizan. Las aplicaciones se integran en el sistema, se prueban como parte del sistema y se prueba el sistema. Los principales resultados de la etapa son aplicaciones listas para usar, probado como parte del sistema para pruebas complejas, una descripción actual de la configuración del software, una versión del sistema ajustada en función de los resultados de las pruebas y documentación operativa del sistema.

Como resultado de dicho diseño se debe obtener. estructura lógica sistemas (subsistemas, módulos, etc.), circuitos de entrada, salida, presentación, conversión de datos, etc.

De acuerdo con las normas legales y la documentación del proyecto, la etapa final de creación del sistema implica pruebas integrales de todos sus componentes, formación de usuarios, administración continua, etc.

Etapa de implementación Incluye actividades para instalar e implementar bases de datos y aplicaciones. El resultado principal de la etapa es una versión del sistema lista para funcionar y transferida a la plataforma de software y hardware del Cliente, documentación de soporte y un informe de prueba de aceptación basado en los resultados de la operación de prueba.

En etapa de operación Se lleva a cabo un control constante (preferiblemente automático) del rendimiento del sistema (monitoreo) para rastrear el estado de los objetos, la detección oportuna de errores y situaciones de emergencia y su desarrollo.

Etapas de mantenimiento y desarrollo. incluyen procesos y operaciones relacionadas con el registro, diagnóstico y localización de errores, realización de cambios y pruebas, realización de mejoras, replicación y distribución de nuevas versiones de software a los lugares de operación, transferencia de aplicaciones a nueva plataforma y escalamiento del sistema. Etapa de desarrollo Es en realidad una repetición de la etapa de desarrollo.

El resultado de la etapa conceptual del diseño AIS es el documento final: "Diseño conceptual", "Diseño avanzado", " Proyecto piloto” o “El concepto y programa de la creación...”. En el futuro se utilizarán predominantemente los términos “proyecto conceptual” y “concepto” o “programa de creación...”.

El diseño conceptual del sistema se caracteriza por plazos ajustados. Por este motivo, los trabajos asociados al mismo y la inspección previa al diseño de la instalación pueden realizarse de forma paralela o solaparse en el momento de su ejecución.

Al diseñar, incl. Al resolver problemas de automatización de procesos, generalmente se adopta inicialmente una de dos opciones: crear un sistema que resuelva problemas inmediatos o incluya tareas a largo plazo (“para el crecimiento”) que tengan en cuenta las necesidades futuras.

En el primer caso, puede elegir una solución económica e implementarla rápidamente. Sin embargo, existe una alta probabilidad de que dicho sistema deba actualizarse o reemplazarse significativamente lo suficientemente pronto.

En el segundo caso, será necesaria una elaboración más seria de los requisitos y soluciones tecnicas, lo que supone un incremento en el tiempo de finalización y coste del proyecto. Pero en este caso es posible prolongar el funcionamiento eficaz del sistema así creado durante un período de tiempo mucho más largo. Sin embargo, las inversiones más grandes conllevan mayores riesgos. Por lo tanto, se recomienda dividir el próximo trabajo en pequeñas etapas, cuya implementación puede traer un resultado concreto y tangible que asegure la solución de la tarea. En este caso, con una inversión mínima, es posible asegurar un retorno rápido y crear una base para un mayor desarrollo del sistema, lo que facilitará, entre otras cosas, el estudio de los resultados obtenidos, el ajuste de acciones futuras, etc. Así, el desarrollo del sistema se vuelve cíclico. Y aunque este enfoque es algo más caro que solución integral tarea a gran escala, le permite reducir los altos riesgos asociados con los cambios en los requisitos del sistema que se está desarrollando.

No se debe pasar por alto que rápido desarrollo La ciencia, la ingeniería y la tecnología conducen al rápido envejecimiento de los métodos y sistemas utilizados, lo que afecta negativamente a la eficiencia de su uso. Al mismo tiempo, es mucho más fácil realizar cambios graduales en los componentes individuales del sistema que reemplazarlos por completo. Además, suele ser necesario garantizar un rápido retorno de la inversión, algo que resulta bastante difícil de organizar cuando se implementan soluciones complejas.

Puedes seleccionar Tres tipos principales de diseño de objetos y sistemas. según su grado de complejidad, volumen y una serie de otros indicadores: proyectos grandes, medianos y pequeños (pequeños).

Al implementar grandes proyectos Por lo general, recurren a la ayuda de grandes empresas integradoras bien establecidas, incluidas organizaciones de consultoría e implementación.

Para implementar proyectos de tamaño mediano, intentan hacerlo usted mismo y (o) utilizar soluciones listas para usar que se esfuerzan por adaptar a los requisitos específicos de la organización del cliente.

Los pequeños proyectos se caracterizan por el uso soluciones listas para usar y, en algunos casos, adaptarlos a condiciones específicas de uso.

diseño de circuitos integrados comienza con la elaboración de un plan de trabajo en forma de texto y (o) gráfico. En la primera etapa de diseño, es necesario conocer los requisitos del usuario para el sistema y, en base a estos requisitos, crear un diseño del sistema. Es preferible diseñar utilizando un método modular. El diseño de sistemas de información está directamente relacionado con su programación, por lo que una parte importante del trabajo de diseño está relacionado con la programación de SI.

Programación modular– un método de desarrollo de programas que implica dividir el programa en módulos independientes. Se cree que el módulo debe tener tamaños óptimos(normalmente caben enteramente en la pantalla) y que la división gran programa en módulos facilita su desarrollo, depuración y mantenimiento.

módulo de software, que combina datos (propiedades) y operaciones sobre ellos (métodos), se denomina objeto.

Objeto- un conjunto abstracto de objetos, todos los cuales tienen las mismas características.

La elección de las herramientas de diseño puede verse influenciada significativamente siguientes características métodos de diseño:

· centrarse en crear un proyecto único o estándar;

· naturaleza iterativa del proceso de diseño;

· la capacidad de descomponer un proyecto en componentes desarrollados por equipos de artistas limitados con integración posterior componentes;

· estricta disciplina de diseño y desarrollo con su naturaleza colectiva;

· la necesidad de alejar el proyecto de los desarrolladores y su posterior soporte centralizado.

Modelos de sala de emergencias
El modelado de dominios se basa en el uso de diagramas gráficos que incluyen un pequeño número de componentes heterogéneos. En 1976, Chen propuso utilizar Modelos de sala de emergencias(Modelo Entidad-Relación) que representa modelos de datos conceptuales. Se utilizan ampliamente en los sistemas CASE modernos que admiten el diseño de circuitos integrados asistido por computadora y generalmente se utilizan en la etapa de modelado lógico de información.

El modelo ER representa claramente los bloques estructurales de información y las relaciones lógicas entre ellos. Los conceptos principales son entidad, relación y atributo (ver tabla).

Tabla de conceptos: entidad, relación y atributo.

El tipo de conexión se indica mediante los índices “1” o “M” encima de la línea correspondiente. Por ejemplo, la relación "Gestión" es del tipo uno a muchos: un empleado puede gestionar muchos proyectos; La relación de “Participación” es del tipo muchos a muchos: un empleado puede participar en muchos proyectos y muchos empleados pueden participar en un proyecto. La figura muestra un ejemplo de un diagrama ER.

Las bases de datos relacionales se forman secuencialmente sobre la base de modelos ER.

Un parámetro importante IS es su facilidad de uso, incluida la garantía de la calidad de la documentación de diseño. Al diseñar, debes centrarte en los siguientes documentos:

GOST 24.602-86. Sistemas de control automatizados. Composición y contenido de la obra por etapas de creación. (Introducido el 01.01.89. – M.: Standards Publishing House, 1986. – 12 p.).

GOST 34.601-90. Tecnologías de la información. Un conjunto de estándares para sistemas automatizados. Sistemas automatizados. Etapas de la creación (Introducida el 29 de diciembre de 1990, 24.601-86. 24.602-86. 1997).

GOST 34.602-89. Un conjunto de estándares para sistemas automatizados. Términos de referencia para crear un sistema automatizado. Ingresar 01/01/90.

GOST 34.603-92. Tecnologías de la información. Tipos de pruebas de sistemas automatizados.

RD 50-640-87. Sistemas de diseño asistido por ordenador. El orden de trabajo al crear sistemas: Instrucciones – M.: Standards Publishing House, 1987. – 28 p. etc.

El diseño conceptual (infológico) (CP) de un sistema es la construcción modelos de informaciónárea temática (DO), que no depende de las condiciones de implementación del software y hardware.

Aquí hay tres funciones:

1. Definición de tipos de entidades de dominio

2. determinar los tipos de relaciones entre entidades

3. definir atributos y vincularlos a tipos de entidades y relaciones.

4. creación de modelos de datos conceptuales locales en forma de diagramas de “entidad-relación”.

5. discusión de LCIMD con los usuarios.

Arroz. 3.1.3.1 Conformidad de las fases de diseño y elementos arquitectónicos ANSI/SPARC.

Etapa de diseño lógico.

El diseño lógico es la construcción de modelos de información basados ​​en módulos conceptuales existentes. Aquellos. En esta etapa el modelo de datos conceptual se transforma en uno local. modelo lógico datos y luego al modelo lógico global de datos (GLDM), teniendo en cuenta el tipo de DBMS utilizado. Esta etapa contiene 2 subetapas:

En primero subetapa realiza:

1. transformación del modelo de datos conceptual local (LCDM) en un modelo de datos lógico local (LLDM);

2. determinación de un conjunto de relaciones (tablas) basadas en la estructura del LLMD;

3. comprobar el LLMD utilizando reglas de normalización;

4. comprobar el LLMD en relación con la transacción del usuario;

5. creación del diagrama entidad-relación final para cada LLMD;

6. determinación de los requisitos para LLMD desde el punto de vista de garantizar la integridad de los datos;

7. Discusión de FSHD con los usuarios finales.

En segundo subetapa realiza:

1. fusión de LLMD en GLMD;

2. comprobar y ajustar el GLMD;

3. creación de la versión final del diagrama “entidad-relación” que muestra el GLMD;

4. Discusión de GLMD con los usuarios finales.

Eso. El diseño conceptual y lógico le permite resolver los siguientes problemas:

1: divida todo el proyecto en un grupo de tareas simples relativamente pequeñas según la estructura del área temática, es decir crear LKMD

2 convierte LKMD a LLMD

3 combinan LLMD en GLMD

Escenario diseño físico

Esta etapa consta de 3 subetapas:

1. implementación de GLMD en el entorno de un DBMS específico:

Diseño de las tablas principales en el entorno DBMS.

Implementación de funciones relacionadas con la gestión de software o así denominadas. reglas de negocio para software

2. crear un proyecto para la representación física de la base de datos:

Seleccionar una estructura de almacenamiento de datos específica

Determinar los requisitos de memoria externa

3. desarrollo de herramientas de protección de bases de datos:

Desarrollar e incorporar cuestiones de protección de datos de los usuarios.

Definición de reglas de acceso para diferentes tipos usuarios

En esta etapa, es necesario considerar cuestiones de monitoreo y configuración de todo el sistema.

Seleccionar un DBMS.

La elección de un DBMS es necesaria para garantizar la forma óptima de soportar una base de datos determinada y todas las aplicaciones de SI. Es aconsejable hacer esta elección entre las etapas de diseño conceptual y lógico, porque esto permite determinar el tipo de DBMS. Seleccionar un DBMS es una tarea bastante laboriosa, porque... varios DBMS difieren significativamente entre sí en todo el grupo parámetros.

lista general Los parámetros incluyen:

1. parámetros físicos:

¿Existen disposiciones para estructuras de archivos en este DBMS;

disponibilidad de herramientas de indexación;

disponibilidad de herramientas de compresión de datos;

posibilidad de cifrado de datos;

cantidades requeridas de RAM y ROM para un DBMS determinado, etc.

2. Parámetros de definición de datos:

tipo de modelo básico de organización de datos;

disponibilidad de soporte para la expansión de clave primaria;

disponibilidad de herramientas de apoyo a la integridad de los datos;

tipos de datos proporcionados;

3. parámetros generales:

Costo del DBMS;

disponibilidad de soporte para el funcionamiento de DBMS en Internet;

rendimiento de este DBMS;

4. Parámetros que determinan la accesibilidad en términos de creación de aplicaciones:

capacidades de lenguaje de consulta;

disponibilidad de acceso multiusuario;

posibilidad de utilizar idiomas nivel moderno;

5. grupo de parámetros que describen los medios de la tecnología de desarrollo de SI:

disponibilidad de herramientas para trabajar con la interfaz de ventana;

disponibilidad de herramientas de caso;

Estos parámetros suelen venir acompañados de ciertos coeficientes de ponderación que determinan el grado de importancia de este parámetro para de este cliente(empresas). Esto permite, utilizando datos numéricos para cada parámetro, calcular un indicador general (integral) para cada DBMS y, por tanto, evaluarlo de forma más objetiva. El cliente y el diseñador de SI seleccionan el DBMS para el cual el indicador de interés es el mayor (mejor).

Desarrollo de aplicaciones.

El propósito del desarrollo de aplicaciones es:

Primero, crear un proyecto de transacción.

2. crear un proyecto de interfaz de usuario.

Diseño de transacciones.

Transacciones: una acción o secuencia de acciones realizadas por el mismo usuario y/o un programa de aplicación (AP), como resultado de lo cual es posible proporcionar acceso a la base de datos y/o cambiar su contenido (ejemplo de transacciones: registro de cliente en la base de datos de cualquier jar).

Normalmente, la transacción la realiza en parte el personal de AIS y en parte la aplicación de software o el propio DBMS.

Principales tipos de transacciones:

1. transacciones extracción– acciones que indican la selección de datos de la base de datos

2. transacciones actualizaciones– acciones que resultan en la eliminación de ciertos datos, su cambio o la adición de algunos datos.

3. mezclado actas

Al diseñar transacciones, es necesario determinar y documentar la naturaleza (propiedades) de todas las transacciones que se implementarán en el AIS. Entre ellos:

1. datos de origen utilizados por la transacción;

2. datos de salida generados por la transacción;

3. características funcionales de las transacciones;

4. grado de importancia de la transacción para el usuario;

5. Se asume la intensidad de uso de esta transacción.