2.1 Формальная запись информационной модели сложного объекта.

НазваниеСложногоТипа(класса) {

//атрибутивная часть

ТипДанныхАтрибута1 НазваниеАтрибута1;

ТипДанныхАтрибута2 НазваниеАтрибута2;

...

//функциональная часть

ТипДанныхРезультатаВыполненияФункции1 НазавниеФункции1(ТипДанныхВходногоПараметра1 НазваниеВходногоПараметра1, ….., ТипДанныхВходногоПараметра_n НазваниеВходногоПараметра_n)

}

Введя (описав) новый сложных тип данных, им можно пользоваться в любом месте, где упоминается тип данных, а именно:

а) при описании атрибута какого-либо объекта,

б) при описании типа возвращаемого значения функции,

в) при описании входного параметра функции.

Следует отметить, что так же можно описывать переменную, являющуюся массивом значений заданного сложного типа данных (см. выше пример с массивом транспортных средств).

Вопросы для самоконтроля:

1. Воспроизведите формат записи атрибута объекта сложного типа (информационной модели)

2. Какие значения может хранить указанный Вами атрибут в вопр. 1?

3. Перечислите типы данных, которые могут задаваться для любого атрибута сложного объекта.

4. Когда возможно использовать простой тип данных при описании атрибута объекта предметной области, а когда — нет?

5. Воспроизведите формат записи функции объекта сложного типа.

6. Какая информация указывается во входных параметрах функции?

7. Информацию какого типа данных может возвращать функция в качестве результата?

8. Какие типы данных могут указываться для входных параметров функции?

2. Требования к построению информационной модели объекта реального мира.

Функциональные и нефункциональные требования.

Задача проектирования информационной модели схожа с задачей создания инструмента или средства для выполнения заданного набора действий. При этом, использование вновь созданного инструмента должно ускорять решение поставленной задачи. Так, создание автомобиля ускоряет решение задачи перемещения из пункта А в пункт В кого-либо или чего-либо. Однако, как только задача начинает обрастать подробностями, к проектируемому транспортному средству начинают предъявляться всё больше и больше требований по функциональности. В результате, на дорогах (асфальтированных и не очень) по всему миру ездят автомобили с разными конструктивными решениями. Эти решения обусловлены требованиями, которые легли в основу при создании данной модели автомобиля.

Таким образом, при создании чего-либо первичным является требования к функциональности итогового изделия («изделия» в широком смысле слова). Теория разработки информационных систем говорит примерно об этом же, но терминами, специфичными для данной отрасли. В частности, при проектировании информационных систем используют следующие термины:

Функциональные требования. Это требования, которые позволяют информационной системе решать поставленные задачи. Например, требование к подсистеме «Бухгалтерия» любого юридического лица, может формулироваться как: «Возможность расчета заработной платы сотрудникам исходя из введенной информации о больничных, количестве отработанных нормо-часов и пр.». К функциональным требованиям так же могут относиться дополнительные характеристики, детализирующие параметры выполнения поставленных задач. Например, указанный выше расчет заработной платы должен выполняться в течение не более 1 минуты для количества сотрудников не менее 1000 человек на компьютере, эквивалентном по мощности 4-х ядерный 1.9 ГГц, 64Гб оперативной памяти IntelХХХ и т. д. Или иметь в качестве дополнительного требования возможность импорта результатов расчета в виде зарплатной ведомости в открытый текстовый формат ODF (OpenDocument Format). Максимально подробное описание функциональных требований в рамках технического задания (ТЗ) необходимо для исключения взаимного непонимания Заказчика и Разработчика информационной системы. Достаточно подробное техническое задание уменьшает риски ошибиться в самом начале и переделывать всё, находясь на заключительных этапах разработки ИС.

Нефункциональные требования. Обычно нефункциональные требования при проектировании информационных моделей объектов формулируются разработчиками этих моделей. Нефункциональные требования описывают вариант реализации функциональных требований. Например, функциональное требование гласит: Пользовательский интерфейс должен иметь возможность запускаться на ПК с ОС Windows, компьютерах Mac и планшетных компьютерах (iPad, Samsung Galaxy, прочие). В результате, разработчик приложения сам выбирает вариант реализации пользовательского интерфейса — будет это браузер или нативное приложение под каждую платформу. Аналогично разработчик может выбирать ту или иную СУБД или язык программирования. Главное, чтобы это позволило реализовать функциональные требования. Однако, из общих соображений понятно, что требование работы в браузере могло быть сформулировано в рамках технического задания. В этом случае данное требование перетекает в область функциональных требований.

Таким образом, «функциональные требования» лежат в области компетенции представителя Заказчика, а «нефункциональные требования» - исполнителя-проектировщика. По сути, нефункциональные требования — это варианты реализации ИС, которые не оговорены в функциональных требованиях, описанных в техническом задании.

Предполагается, что учащиеся при изучении материала ориентируются в бизнес и технологических процессах предметной области и способны в укрупненном виде формулировать те самые функциональные требования.

Вопросы:

1. Что лежит в основе проектирования информационной системы?

2. Могут ли нефункциональные требования быть частью технического задания, которое формулирует Заказчик?

3. Может ли проектирование Системы обойтись без функциональных требований?

4. Как наличие нефункциональных требований в ТЗ может влиять на качество разрабатываемой ИС?

5. Как наличие нефункциональных требований в ТЗ может влиять на стоимость разрабатываемой ИС?