Моделът на дизайна на списъка с материали е измамно прост, но невероятно мощен. Тази статия ще представи пример, познат на ИТ специалистите, за който може би не сте смятали, че отговаря на модела на спецификацията. Той също така ще въведе концепции, за да ви покаже как да направите структурите на спецификацията си по-гъвкави и много по-лесни за управление.
Кратко обобщение на спецификацията
Слитна спецификация има своите корени в производството. Това е списък на суровините, подвъзлите, междинните възли, подкомпонентите, частите и количествата от всеки, необходими за производството на краен продукт.
В най-простата си форма, класическата структура на спецификацията, тя изглежда така:
Въпреки това една и съща структура може да се използва за множество различни цели , които варират от нещо строго йерархично и тясно свързано до нещо доста плоско и слабо свързано. За повече информация относно структурата на спецификацията вижте тази статия.
Схеми – ежедневен пример
Вярвате или не, триплетът от тип атрибут-клас и триплетът от тип таблица-колона също следват модела на спецификацията. Физическият модел на данни по-долу съдържа основните таблици на речник с данни.
| Таблица | Описание |
|---|---|
| dd_attribute | Уникален атрибут, независим от каквато и да е реализация. |
| dd_attr_instance | Екземпляр на атрибут. Инстанцията има две отличителни връзки: 1) Класът, към който принадлежи, който може да бъде логически или физически обект. Екземплярът е уникален за този клас. 2) Типът данни, който може да бъде или роден тип, или друг тип клас. |
| dd_class | Клас или обект в общия смисъл – действителната реализация се дава от class_type – който има набор от атрибути. |
Речник на данни или хранилище на метаданни се дефинира в IBM Dictionary of Computing като "централизирано хранилище на информация за данни като значение, връзки с други данни, произход, използване и формат".
Сега помислете за следната дефиниция на XML схема (XSD) за Java приложение:
Той дефинира сложни типове XSD, които имат атрибутите на всеки собствен тип XML – напр. низ , NMTOKEN , anySimpleType – или други сложни типове.
За да започнем да попълваме речника с данни за горния XSD, първо трябва да въведете XML родните типове данни като класове :
| class_name | стереотип |
|---|---|
| булева | Вроден |
| дата | Вроден |
| dateTime | Вроден |
| низ | Вроден |
| версия | Вроден |
| NMTOKEN | Вроден |
| anySimpleType | Вроден |
Вече имаме всичко необходимо, за да започнем да попълваме нашия речник с данни. В примера по-долу е показано достатъчно, за да се дефинира напълно ConnectionConfigType сложен тип.
| dd_attribute | от_клас (чрез dd_attr_instance) | type_class (чрез dd_attr_instance) | ||
|---|---|---|---|---|
| attr_name | име_на клас | стереотип | име_на клас | стереотип |
| ключ | PropertyType | XSDcomplexType | низ | Вроден |
| стойност | PropertyType | XSDcomplexType | низ | Вроден |
| Свойство | ConnectionConfigType | XSDcomplexType | PropertyType | XSDcomplexType |
| driverClassName | ConnectionConfigType | XSDcomplexType | низ | Вроден |
| потребител | ConnectionConfigType | XSDcomplexType | низ | Вроден |
| парола | ConnectionConfigType | XSDcomplexType | низ | Вроден |
| Име на басейн | ConnectionConfigType | XSDcomplexType | низ | Вроден |
Обърнете внимание как типът данни на ConnectionConfigType.Property атрибутът е друг сложен тип, PropertyType . В XML сложните типове могат да бъдат съставени от други сложни типове. Не е необичайно да намерите вложени сложни типове в XML документи, особено в WSDL.
И какво от това? ти питаш. Е, като се има предвид, че XML е йерархичен по структура и сложните типове могат да се използват повторно, XML естествено следва модела на спецификацията .
И това явление не се ограничава до XML. Други схеми, като тези за JSON и обектно-релационни бази данни, също следват модела на спецификацията .
Включване на гъвкавост в спецификация
В класическата структура на продуктовата спецификация три по-фини концепции участват в моделирането на това, което се случва в реалния свят. Това са алтернативи ,варианти , иревизии .
Елтернативата е заместител на определен артикул. Например, производител на автомобили може да има различни доставчици за определени артикули. На практика това означава, че производителят може да получи еквивалентни горивни помпи от множество източници. Обикновено на клиента не се предоставя тази опция, но тя дава на производителя гъвкавост.
Използвахме горивни помпи като елементи в примерната таблица по-долу, с Bosch и Lucas като алтернативи. Наличието на алтернатива на горивната помпа означава, че една и само една от възлите ще бъдат избрани по време на производството на двигателя.
| Елемент | Алтернатива | |
|---|---|---|
| Родител | Дете | Количество |
| V6 (монтаж) | Горивна помпа (алтернатива) | 1 |
| Горивна помпа (алтернатива) | Помпа Bosch (монтаж) | |
| Горивна помпа (алтернатива) | Помпа Лукас (монтаж) | |
Вириант е друг вид артикул, но този път клиентът прави избора. Купувачът на автомобил може да избере различни модели на каросерията – с 3 врати, 5 врати или комби (комби или комби). Те също така могат да избират между два различни типа двигател – V6 или V8. В нашия пример купувачът трябва да избере един и само един от комплектите под варианта.
| Елемент | Вариант | ||
|---|---|---|---|
| Родител | Дете | Минимален избор | Максимален избор |
| Автомобил (монтаж) | Тяло (вариант) | 1 | 1 |
| Тяло (вариант) | 3 врати (монтаж) | ||
| Тяло (вариант) | 5 врати (монтаж) | ||
| Тяло (вариант) | Имот (Сглобяване) | ||
| Автомобил (монтаж) | Двигател (вариант) | 1 | 1 |
| Двигател (вариант) | V6 (монтаж) | ||
| Двигател (вариант) | V8 (монтаж) | ||
В други области броят на изборите е по-разнообразен. Вземете образованието за пример. За да придобие определена квалификация, ученикът трябва да завърши определен брой групи. За всяка група те могат да избират от няколко модула.
Например, да предположим, че студент трябва да завърши две групи, за да получи диплома. Те могат да изберат два модула от списък с шест, за да завършат първата група. След това те трябва да изберат три модула от пет, за да завършат втората група. (Ако това е сектор, който бихте искали да видите по-подробно, гъвкав дизайн е публикуван от Съвета за информационни стандарти на Обединеното кралство.)
И двата горни примера следват простия модел, показан по-долу. Този модел се поддава на структури, които са доста статични. Вариантите и алтернативите се вмъкват в йерархията, за да се посочи, че трябва да се направи някакъв избор от елементите непосредствено под тях.
Когато нещата са склонни да се променят с времето, следният модел е по-гъвкав и по-лесен за поддържане. От друга страна, е малко по-трудоемко за преминаване (или навигация).
Чрез трансформирането на горния логически модел във физически модел, нещата започват да изглеждат така:
В този модел артикулът е или неделима част, или сглобка. Частите и възлите са организирани в йерархии. Обачеалтернативи ,варианти и ревизиии имат свои собствени отделни взаимоотношения, защото са склонни да се променят доста с течение на времето. Това свежда до минимум реорганизацията на йерархията.
Например производителите на автомобили непрекъснато развиват своите автомобили. От това следва, че алтернативите на частите се променят с времето, както и вариантите, предоставени на клиента. Когато настъпи промяна в един монтаж, той се ревизира. Аревизия показва историята на промените на артикула. Помислете за този пример:
| Номер на част | Версия | Предишна | Последващи |
|---|---|---|---|
| 123456-1 | 1 | 123456-1 | 123456-1 |
| 123456-2 | 2 | 123456-1 | 123456-2 |
| 123456-3 | 3 | 123456-2 | 123456-3 |
| 123456-4 | 4 | 123456-1 | 123456-4 |
| 123456-5 | 5 | 123456-2, 123456-3 | 123456-5 |
Разказът за горната таблица е следният:един елемент има поне една ревизия – оригиналната му версия. Оригиналната версия на продукта се използва за създаване на втората версия. Втората беше доразвита, за да създаде трета версия, която не се получи. Така инженерите преразгледаха оригиналната версия, създавайки четвърта версия. След задълбочени тестове се оказа, че това също не е идеално. Затова инженерите решиха да вземат аспекти на втората и третата версия и да създадат версия пет, крайният продукт.
Ако погледнете предишния и следващите ключове, ще видите защо историята на промените се нуждае от много към много връзка между елементи и ревизии. Същият принцип се прилага между артикули, алтернативи и варианти.
Последна дума за модела на спецификацията
Надявам се, че тази серия от статии ви е помогнала да разпознаете модела на спецификацията. Когато се появи във вашите проекти, ще разберете как най-добре да го моделирате във вашия конкретен домейн.
Моля, имайте предвид обаче, че стриктната структура на спецификацията има плюсове и минуси. Pro:йерархиите могат да се използват повторно. Против:йерархиите могат да се използват повторно. Това може и да не е нещо лошо във вашия случай, но със сигурност е нещо, което трябва да знаете.
Хубавото е, че йерархиите не трябва да се поставят в камък. Използвайки алтернативи, варианти и ревизии, можете да моделирате домейни, където съществуват опции, където историческата позиция трябва да бъде запазена и в крайна сметка, където единствената константа е промяната.
