Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Программа'
корпус «Приморский»    В стоимость путевки на Новогодний тур включено: · проживание; · 3-х разовое питание «шведский стол»; · новогодний банкет с шоу-...полностью>>
'Документ'
Разработка индивидуальных программ для работы с детьми «группы риска». Качественное ведение банка данных детей, охваченных различными видами контроля....полностью>>
'Документ'
по аккредитации граждан и организаций, привлекаемых Республиканской службой государственной жилищной инспекции к проведению мероприятий по контролю в ...полностью>>
'Руководство'
Руководство подготовкой и проведением турнира осуществляет Федерация шахмат Таттинского улуса и комитет спорта администрации МР «Таттинский улус». Неп...полностью>>

Главная > Документ

Сохрани ссылку в одной из сетей:
Информация о документе
Дата добавления:
Размер:
Доступные форматы для скачивания:

Дзюба Д.В., Крылов С.С.

АВТОМАТИЗИРОВАННОЕ МОДЕЛИРОВАНИЕ ПРОГРАММНЫХ СИСТЕМ

Учебное пособие

Москва, 2002

© Д.В. Дзюба, С.С. Крылов

Введение

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

Под программной системой (ПС) понимается [1] совокупность программ и сведений, требуемых для их эксплуатации, предназначенная для решения определенного круга задач.

Наибольший практический интерес представляют индустриально организованные ПС, которые характеризуются:

  1. Длительным временем эксплуатации;

  2. Сравнительно широким кругом пользователей, результат работы которых зависит от нормального функционирования программных средств;

  3. Коммерческой ценностью.

Примерами таких систем могут служить системы контроля за реальными процессами (грузоперевозки, химический синтез), информационно-поисковые системы, системы программирования, офисные пакеты.

Согласно [2] разработка индивидуальных («малых») проектов отличается от индустриально организованных («больших») следующими признаками:

«малые» проекты

«большие» проекты

Код разрабатывается единственным программистом или, возможно, небольшой группой программистов. Отдельно взятый индивидуум может понять все аспекты проекта, от и до.

Программная система разрабатывается большой командой программистов. При этом одна группа может заниматься проектированием (или спецификацией) системы, другая — осуществлять написание кода отдельных компонент, а третья — объединять фрагменты в конечный продукт. Нет единственного человека, который знал бы все о проекте.

Основная проблема при разработке состоит в проектировании программы и написании алгоритмов для решения поставленной задачи.

Основная проблема в процессе разработки — управление проектом и обмен информацией между группами и внутри групп.

В настоящее время наблюдается тенденция «глобализации» программных проектов, то есть увеличение среди разрабатываемых и эксплуатируемых программ количества сложных интегрированных программных систем, компоненты которых распределены между рабочими местами. Далее рассматриваются, главным образом, индустриально организованные ПС.

Индустриально организованным ПС присуща сложность, определяемая шестью основными причинами [1],[3]

  1. Сложностью постановки решаемой задачи (неформальные, неявные, противоречивые требования);

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

  3. Сложностью описания поведения отдельных подсистем;

  4. Сложностью управления процессом коллективной разработки (ПС не создаются одиночками, следовательно, возникают проблемы связи между разработчиками, синхронизации их действий, обеспечения целостности и непротиворечивости проекта);

  5. Сложностью обеспечения открытости ПС (ПС для этого должна соответствовать различным стандартам).

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

Один из основных способов преодоления сложности - разбиение системы на более простые подсистемы, т.е. декомпозиция системы, порождающая иерархию абстракций.

Следуя Г. Бучу [4] выделим два вида декомпозиции:

  1. Алгоритмическая. Главное - порядок событий, функциональность. Исторически более ранний вид декомпозиции, соответствовал возможностям и задачам ранних ЭВМ, по сути более близок архитектуре фон-Неймановских машин.

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

Для построения функциональных моделей разработано значительное количество методологий. Одной из наиболее распространенных является методология SADT, которая и рассматривается в данном пособии. Также излагаются основы методологии UML, являющейся фактическим стандартом объектного моделирования. Для обеих методологий приводятся примеры их использования для решения учебной задачи.

Методология SADT

Первоочередной проблемой, возникающей перед разработчиками при проектировании ПС, является анализ предметной области, выявление целей и ключевых закономерностей ее функционирования. Качество выполнения этого этапа во многом определяет успех или неуспех проекта в целом, поскольку ошибки, допускаемые на ранних стадиях разработки системы обходятся особенно дорого. Результаты анализа желательно фиксировать таким образом, чтобы соблюдался баланс между степенью формализации предметной области и наглядностью представления. Для этой цели удобно использовать некоторую стандартизованную графическую нотацию, разумеется, в сочетании с текстовыми комментариями. На практике в качестве средства предварительного описания предметной области более двадцати лет широко и успешно применяется методология SADT - Structured Analysis and Design Technique (Технология структурного анализа и проектирования), включающая наглядные графические средства и подход к описанию систем. Часть этой методологии, связанная с функциональным моделированием, известна под названием IDEF0 – сокращение от ICAM (Integrated Computer Aided Manufacturing - интегрированная компьютеризация производства) DEFinition. Предварительное описание предметной области часто основывается на функциональном SADT моделировании с помощью SADT- диаграмм. Почему для предварительного описания часто используется функциональное, а не объектное моделирование? Это обусловлено несколькими причинами:

1. Для данного этапа проектирования характерно интенсивное взаимодействие разработчиков с экспертами в предметной области в ходе совместного построения и обсуждения модели. Эксперты в предметной области как правило не имеют (да и не обязаны иметь) навыков работы со сложными методами моделирования, но нуждаются в средствах формализации знаний. Практика показывает, что во многих случаях методология SADT является оптимальным компромиссом между сложностью изучения методологии неспециалистами в системном анализе, выразительностью и информационной насыщенностью модели.

2. Функциональные модели часто более понятны неспециалистам, чем объектные. Это обусловлено исторически сложившимся преобладанием описаний систем в терминах функций, входов и выходов над объектными описаниями в технической документации, учебной литературе и других традиционных источниках знаний о большинстве предметных областей. Такая ситуация не может не сказываться на менталитете экспертов, и с этим нужно считаться.

3. При предварительном анализе функции и взаимосвязи между ними часто легче выявить чем классы и их взаимоотношения.

4. Выявленные функции и потоки данных между ними впоследствии удобно использовать как основу объектной декомпозиции.

5. Графический язык SADT содержит всего один примитив для представления действия (блок) и один примитив (дугу) для выражения связи между блоками.

Влиятельным фактором распространения SADT являются некоторые корпоративные и государственные стандарты ряда стран, в первую очередь CША, предписывающие использование этой методологии в определенных категориях проектов.

Модель

SADT-модель должна давать полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, следует из формального определения модели в SADT [3]: М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с требуемой точностью. Множество возможных вопросов определяется выбранной при моделировании точкой зрения на систему. Например, модель завода, построенная с точки зрения главного бухгалтера, ориентированная на финансовые потоки и документооборот, будет существенно отличаться от модели того же завода, созданной с точки зрения начальника производства и совсем не будет похожа на модель функционирования завода с точки зрения ночного сторожа (например, он может представлять завод как огороженное пространство, изобилующее материальными ценностями и их потенциальными расхитителями). Заметим, что во многих случаях SADT-модели реальных предметных областей имеют самостоятельную практическую (в том числе коммерческую) ценность, поскольку они могут быть использованы для реинжиниринга или, скажем, обучения персонала.

Основная часть SADT-модели системы представляет собой набор диаграмм, объединенный в древовидную структуру. Каждая диаграмма представляет собой описание некоторой четко ограниченной функции данной системы на определенном уровне абстракции. Диаграмма в корне дерева соответствует наиболее абстрактному описанию системы, ясно выражающему свободную от деталей концепцию системы с заданной точки зрения. Она называется контекстной диаграммой. Диаграммы дочерних вершин детализируют диаграмму родительской вершины. Диаграммы терминальных вершин соответствуют максимальному уровню детализации. Пример дерева диаграмм приведен в приложении С.

В SADT-модель входят также текстовые описания и комментарии.

Диаграмма

На SADT-диаграмме располагаются блоки и ориентированные дуги. Диаграмма составляется на стандартном бланке, в котором предусмотрены поля для названия, автора, наименования проекта, даты составления или изменения и другой стандартной информации.

Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отображают взаимодействия и взаимосвязи между ними. Методология SADT рекомендует, чтобы на диаграмме находилось не менее трех и не более шести блоков. Исключением является диаграмма самого высокого уровня, которая всегда содержит один блок, выражающий обобщенную функцию системы. Правило «от трех до шести» было получено эмпирическим путем. Считается, что диаграмма из двух блоков слишком тривиальна, а из семи и более – сложна для понимания. Выбор числа семь в качестве границы косвенно подкрепляется некоторыми рекомендациями из области организации управления, согласно которым наличие у начальника более шести заместителей исключает эффективную координацию их действий. Если на диаграмме получается более шести блоков, то следует либо укрупнить некоторые из них, либо пересмотреть структуру дерева диаграмм.

Блоки изображаются прямоугольниками. Название представляемой блоком функции пишется внутри блока обычно в неопределенной глагольной форме («выписать ордер», «проверить и утвердить баланс», «загрузить управляющую программу», «загерметизировать швы» и т.д.). Дуги располагаются и нумеруются на диаграмме вдоль диагонали из левого верхнего угла в правый нижний. Меньший номер соответствует более высокой степени доминирования блока. Доминирование блока может быть обусловлено тем, что его функция выполняется ближе к началу последовательного процесса или важностью его функции. Например, доминирующим может быть блок, содержащий функции управления выполнением работы. Порядковый номер блока пишется в углу прямоугольника и используется для ссылки на декомпозирующие его диаграммы.

Дуги могут исходить из левого, верхнего, нижнего края диаграммы или из правого края блока. Дуги присоединяются к левому, верхнему, нижнему краю блока или правому краю диаграммы. Дуга может вести от блока к нему самому. Дуга пред­ставляет множество внешних по отношению к блоку объектов, участвующих в выполнении его функции. «Быть результатом» также означает участие в выполнении функции. Под объектами здесь понимаются и физические сущности (материалы, изделия, оборудование, персонал, документы и др.) и более абстрактные информационные (указания, потребности, сведения о наступлении событий и т.д.). Дуги могут сливаться и разветвляться, что соответствует объединению или разделению множеств объектов.

Название соответствующих дуге объектов пишется вдоль нее преимущественно в форме подлежащего, возможно, с дополнениями и определениями («утвержденный баланс», «бракованное изделие», «нормы законодательства РФ», «оператор», «таблица активных процессов» и т.д.). По роли в выполнении функции блока дуги подразделяются на входные ( присоединяются к левой стороне блока), выходные (исходят из правой стороны блока), управляющие (присоединяются к верхней стороне блока) и дуги механизмов (к нижней стороне блока). Входные дуги соответствуют объектам, исполь­зуемыми и преобразуемыми функцией блока. Выходные дуги изображают объекты, в которые преобразуются входы. Управляющие дуги обычно содержат условия выполнения функций и ограничения, учитываемые при их работе. Дуги механизмов раскрывают средства, которыми производится выполнение функций.

Дуги, соединенные с краем диаграммы или присоединенные к блоку только одним концом являются внешними по отношению к данной диаграмме и выражают ее связь с внешним миром или другими подсистемами декомпозируемой системы. Остальные дуги являются внутренними по отношению к данной диаграмме. Если некоторый блок подвергается декомпозиции, то все инцидентные ему дуги будут внешними на декомпозируемой диаграмме. Это важное правило SADT, следование которому обеспечивает преемственность и непротиворечивость родительских и дочерних диаграмм.

Рисунок.

При декомпозиции блока 2 диаграммы A1 дуги A,B,C,D,E станут внешними для детализирующей диаграммы A12, например, следующим образом:

Для идентификации внешних дуг в SADT принята система ICOM – обозначений. ICOM – сокращение от Input (вход), Control (управление), Output (выход), Mechanism (механизм). ICOM-нумерация внешних дуг выполняется следующим образом: входы кодируются литерой I и номером соответствующей дуги для родительского блока на декомпозируемой диаграмме. Аналогично для дуг управления (C), выходов(O) и механизмов(M). Нумерация дуг ведется сверху вниз для входов и выходов и слева направо для управляющих дуг и механизмов.

Заметим, что на диаграммах низкого уровня абстракции (и, соответственно, высокой степени детализации) может возникнуть потребность в использование большого числа внешних дуг, механическое перенесение которых на другие диаграммы нежелательно. В этом случае используются так называемые туннельные дуги (со скобочками), реализующие исключение из сформулированного выше правила декомпозиции диаграмм. Аналогично, некоторые дуги на родительских диаграммах иногда нежелательно переносить на дочерние, например, в тех случаях, когда дуга с родительской диаграммы связана со всеми блоками декомпозирующей диаграммы, но изображение всех этих связей нежелательно по соображениям наглядности. Туннельные дуги являются локальными по отношению к диаграмме и по выражению [3] позволяют “спрятать” некоторые подробности и показать необходимые детали.

Пример:

Дуга А не будет видна на родительской диаграмме; дуга B не будет видна на диаграмме, декомпозирующей блок 2; дуга C не будет видна ни на родительской, ни на декомпозирующей блок 3 диаграмме.

Дуги SADT позволяют отображать на диаграммах не только последовательное и параллельное выполнение функций, но и обратную связь между блоками системы. В SADT различается два вида обратной связи – по потоку данных (выход – вход) и по управлению (выход – управление). Обратная связь по управлению свидетельствует о взаимном влиянии функций, тогда как обратная связь по потоку данных указывают на повторное использование и итерацию [3].

Последовательное и параллельное выполнение функций.

Примеры обратной связи. А- обратная связь по управлению, B – по данным.

Для большей наглядности сложных диаграмм рекомендуется продумать и использовать систему выделения цветом и толщиной линии дуг и блоков. Особенно это важно для сложных диаграмм с большим количеством пересекающихся дуг.

Атрибуты диаграммы

В верхней части бланка диаграммы размещаются следующие атрибуты (cм. рис):

  • Автор

  • Название проекта

  • Дата создания

  • Информация о рецензировании

  • Статус диаграммы (рабочая версия/эскиз/рекомендовано/публикация)

В поле «контекст» схематически изображается положение декомпозируемого блока на родительской диаграмме, для корневой диаграммы там пишется слово TOP (верхний). В нижней части диаграммы указывается ее название, совпадающее с названием декомпозируемого блока, а также индекс диаграммы в дереве модели (обозначение узла) и номер диаграммы в модели (С-номер). С-номер формируется из первых трех букв имени автора и последовательного номера, соответствующего хронологическому порядку создания диаграмм. Если в папке модели появляется новая версия диаграммы то рядом с ее С-номером указывается С-номер предыдущей версии. Обозначение узла для контекстной (корневой) диаграммы формируется из полного или сокращенного названия проекта, символа «/», буквы А (сокращение от Activity – деятельность), символ «-» и 0 – индекс корневой диаграммы. Обозначение узла диаграммы, декомпозирующую контекстную такое же, только без знака «-». Все другие номера узлов образуются посредством добавления к номеру узла родительской диаграммы номера декомпозируемого блока. Ведущий ноль в обозначении узла обычно не пишется, поэтому вместо ххх/А01 пишется ххх/А1.

Создание SADT- модели

Создание функциональной модели системы представляет собой с одной стороны алгоритмизированную процедуру, а с другой стороны оставляет простор для творчества автора. Методология SADT содержит рекомендации, обобщающие опыт декомпозиции реальных систем, следование которым позволяет повысить эффективность и качество моделирования. В создании SADT-модели выделяется следующая последовательность этапов:

  • Начало моделирования – на этом этапе производится сбор информации о моделируемой системе, выбор цели модели и точки зрения, разграничение системы и внешней среды, оформленные в виде диаграммы A0 и контекстной диаграммы А-0.

  • Выбор блоков, нуждающихся в декомпозиции и построение детализирующих их диаграмм.

  • Критический анализ построенной модели и, возможно, возврат к предыдущим этапам.

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

SADT содержит ценные указания по сбору информации (извлечению знаний) о системе. Они описаны в [3] и частично приводятся здесь в виде таблицы.

Стратегии сбора информации

Преимущества

Недостатки

Рекомендации по применению

Опрос экспертов (специалистов в данной предметной области).

Эксперты, как правило, наилучшие источники информации о системе. Им известны текущие нюансы и недокументированные аспекты системы.

Эксперты обычно не готовы формально или хотя бы систематически изложить свои знания в нужных пределах.

Необходимо тщательно планировать выбор собеседника и круг обсуждаемых вопросов.

Чтение документов.

Доступность документов, их статичность.

Могут неточно отражать реальную ситуацию (утрата актуальности с течением времени, наличие недокументированных нюансов системы).

Использовать для получения первоначального представления о системе и в ходе подготовки к опросу экспертов.

Вести библиотеку документов.

Наблюдение за выполнением операций

Реальная информация “из первых рук”.

Не всегда возможно.

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

При возможности, не только наблюдать но и участвовать.

Анкетирование

Позволяет опросить большие группы экспертов в сжатые сроки.

Практика показывает, что результаты анкетирований часто субъективны и недостаточно достоверны.

Использовать после достаточного знакомства с системой, что позволяет тщательно подготовить вопросы и избежать непонимания и раздражения респондентов.

Рекомендуется использовать для выявления наиболее существенных проблем в системе.

Использование собственных знаний

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

Применение ограничено. Для выявления специфики системы необходимы другие стратегии.

Необходим значительный личный опыт анализа систем.

Составление описания системы и обсуждение его с экспертами

Стимулирует поиск альтернативных решений.

Эксперты могут не быть готовы к восприятию новых возможностей.

Следует предварительно изучить предметную область и сформировать доброжелательно настроенную группу экспертов

Важной частью этапа начала моделирования является построение диаграммы A0, на которой изображаются основные функциональные блоки системы и связывающие их объекты. Для выявления основных объектов и функций при построением диаграммы A0 рекомендуется составить подробные перечни объектов и функций системы. Эти перечни вначале представляют собой просто список терминов, выявленных при сборе информации о системе. Не страшно, если список терминов будет избыточным, поскольку лучше его впоследствии сократить, чем изначально пропустить нечто существенное. Затем из списка терминов выбираются объекты, их перечень подвергается критическому анализу, на предмет исключения ненужных и объединения родственных объектов. Здесь также необходимо разграничить внутренние объекты системы, внешние, и интерфейсные, т.е. связывающие систему с внешним миром. Далее следует сделать предположения о роли выделенных объектов в системе (преобразуемые данные, управление, механизм) и перейти к работе со списком функций. Здесь требуется «увязать» функции с данными и сгруппировать функции в 3-6 блоков (подсистем) по признаку общности данных и назначения. Расположив эти блоки с учетом доминирования и соединив дугами, получим диаграмму A0. Контекстная диаграмма А-0 легко получается обобщением диаграммы А0. Заметим, что процесс построения диаграмм часто бывает итерационным и, возможно, потребуется их неоднократная корректировка.

Следующим большим этапом является декомпозиция блоков. Критерием окончания процесса декомпозиции является достижение поставленной цели моделирования. Начинать декомпозицию рекомендуется с самого насыщенного функциями блока. Процесс декомпозиции блока сходен с процессом создания диаграммы A0. Разница заключается в том, что для детализируемого блока уже известны его внешние интерфейсы и мы обладаем более подробными знаниями о системе в целом. Необходимые пояснения к вновь создаваемым диаграммам должны сразу же включаться в папку модели системы.

Критический анализ модели должен дать ответ на вопрос – соответствует ли модель формальным требованиям SADT и в какой степени достигнута цель моделирования? Для ответа на этот вопрос следует сначала уточнить цель и точку зрения моделирования, изучить контекстную диаграмму и структуру модели в целом. Критический анализ отдельных диаграмм состоит в их синтаксическом и семантическом контроле. Распространенными синтаксическими ошибками являются:

  • Неверная нумерация блоков или диаграмм, отсутствие названия у дуги

  • Наличие блоков, не имеющих выхода или входа.

  • Несовпадение дуг блока и внешних дуг его декомпозиции

Семантический контроль заключается в нахождении ответа, в частности, на следующие вопросы с учетом цели и точки зрения моделирования [3]:

  • Не перекрываются ли функции различных блоков?

  • Нет ли избыточной детализации блоков?

  • Нет ли недостаточно детализированных блоков?

  • Всегда ли названия блоков и дуг понятны и однозначны?

  • Всегда ли одинаковые термины используются в одном и том же смысле?

  • Нет ли на одной диаграмме блоков или дуг явно относящихся к далеким друг от друга уровням иерархии абстракций?

  • Нет ли ненужных дуг, касающихся блока?

  • Не является ли диаграмма слишком запутанной?

  • Всегда ли обоснованно используются туннельные дуги?

  • Не следует ли некоторые дуги поместить в туннель?

Крайне желательно выполнение критического анализа не только автором, но и коллегами, а также экспертами SADT и предметной области в форме совместного обсуждения или рецензирования. Еще раз подчеркнем, что построение функциональной декомпозиции представляет собой итерационный процесс с постоянным совершенствованием модели.

В приложении С приведен пример функциональной SADT-модели, построенной для решения учебной задачи – выполнения начального этапа проектирования CASE-системы.



Похожие документы:

  1. Українці: народні вірування, повір`я, демонологія

    Документ
    ... . 7. Сатана, черный, с хвостом, с крыльями летучей мыши, с огромными рогами и с угольком ... ? На маковци сыдила, Дрибен мачок дзюбала; Дзюб, дзюб, дзюбанець. Ходы, дивко, у танець. ... . ПОТРУХИ В ЮШЦИ. Гусиные лапки, крылья, печенки, почки, пупки сложить в ...
  2. К 1933 г на вооружение поступили торпеды тан-12 для низкого торпедометания (с бреющего полета) и тав- 15 для сброса с парашютами, а также авиационная мина мав

    Документ
    ... иногда именовали "агрегат т. Дзюбе"). После многократных поломок 9 ... ускорить применение: подкрылков, закрылков, двойного крыла, крыла с меняющимся профилем..., имея в виду ... документах иногда именовали "агрегат т. Дзюбе"), которые шли с 23 января ...
  3. 100 великих операций спецслужб

    Документ
    ... ) о том, что Майклу Дзюбе гарантируется гражданство Канады и убежище ... высших должностных лиц на «гарантиях» «Дзюбе» и «Стаднику». Журналист информировал ... похищении и убийстве Нина, главы троцкистского крыла испанской компартии. Были и героические ...
  4. Российская благотворительность в зеркале сми (1)

    Документ
    ... детей царя Алексея Михайловича. Олег Дзюба, «Российская Федерация сегодня» (Москва), ... детей царя Алексея Михайловича. Олег Дзюба, «Российская Федерация сегодня» (Москва), ... , согласилось на финансовую поддержку «Крыльев Советов». С логотипом «Российских ...
  5. Справочник "Освобождение городов: Справочник по освобождению городов в период Великой Отечественной войны 1941-1945" / М. Л. Дударенко, Ю. Г. Перечнев, В. Т. Елисеев и др. М.: Воениздат, 1985. 598 с

    Справочник
    ... генерал-полковник И. С. Конев) и правого крыла Юго-Западного (командующий Маршал Советского ... 62-й истребительной авиабригады (полковник Дзюба Георгий Георгиевич), часть сил 63 ... ТОФ (генерал-майор авц. Дзюба Георгий Георгиевич). ЮЖНО-САХАЛИНСК, см ...

Другие похожие документы..