Методика CDM выделяет следующие процессы, протекающие на протяжении жизненного цикла информационной системы:
□ определение производственных требований;
□ исследование существующих систем;
□ определение технической архитектуры;
□ проектирование и построение базы данных;
□ проектирование и реализацию модулей;
□ конвертирование данных;
□ документирование;
□ тестирование;
□ обучение;
□ переход к новой системе;
□ поддержку и сопровождение.
Процессы состоят из последовательностей задач, задачи разных процессов связаны с помощью явно обозначенных ссылок.
Особенности методики CDM
Отметим основные особенности методики CDM, определяющие область ее при-менения и присущие ей ограничения.
□ Степень адаптивности CDM ограничивается тремя моделями жизненного цикла:
■ классическая модель предусматривает все этапы;
■ быстрая разработка ориентирована на использование инструментов моде-лирования и программирования Oracle;
■ облегченный подход рекомендуется в случае малых проектов и возможности быстро прототипировать приложения.
□ Методика не предусматривает включение дополнительных задач, которые не оговорены в CDM, и их привязку к остальным. Также исключено удаление задачи (и порождаемых ею документов), не предусмотренное ни одной из трех моделей жизненного цикла, и изменение предложенной последовательности выполнения задач.
□ Все модели жизненного цикла являются по сути каскадными. Даже «облегченный подход», несмотря на итерационность действий по прототипированию, сохраняет общий последовательный и детерминированный порядок выполнения задач.
□ Методика не является обязательной, но может считаться фирменным стандартом. При формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптации.
□ Прикладная система рассматривается в основном как программно-техническая система, например, возможность выполнения организационно-структурных преобразований, практически всегда происходящих при переходе к новой ин-формационной системе, в этой методике отсутствует.
□ CDM теснейшим образом опирается на инструментарий Oracle, несмотря на утверждения о простоте адаптации CDM к проектам, в которых используется другой комплект инструментальных средств.
□ Методика CDM представляет собой вполне конкретный материал, детализи-рованный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах информационных систем с опорой на инструментальные средства и СУБД фирмы Oracle.
Билет 44.
Общая структура
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жиз-ненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов (приобретение, поставка, разработка и т. п.). Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие — на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируется и выполняется другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
Основные и вспомогательные процессы жизненного цикла
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла про-граммного обеспечения.
□ Процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу.
□ Процесс поставки определяет действия предприятия-поставщика, которое снаб-жает покупателя системой, программным продуктом или службой.
□ Процесс разработки определяет действия предприятия-разработчика, которое раз-рабатывает принцип построения программного изделия и программный продукт.
□ Процесс функционирования определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в целом (а не только программного обеспечения) в процессе ее функционирования в интересах пользователей. В от-личие от действий, перечисленных разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности.
□ Процесс сопровождения определяет действия персонала, обеспечивающего со-провождение программного продукта, то есть управление модификациями про-граммного продукта, поддержку его текущего состояния и функциональной пригодности; сюда же относятся установка программного изделия на вычисли-тельной системе и его удаление.
Помимо основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла программного изделия и обеспечивают должное качество проекта программного обеспечения. К вспомогательным процессам относятся:
□ решения проблем;
□ документирование;
□ управление конфигурацией;
□ обеспечение качества;
□ верификация;
□ аттестация;
□ совместная оценка;
□ аудит.
В стандарте ISO 12207 также определяются четыре организационных процесса:
□ управление;
□ создание инфраструктуры;
□ усовершенствование;
□ обучение.
Билет 45.
Особенности стандарта ISO 12207
Все сказанное выше позволяет сформулировать некоторые особенности стандарта ISO 12207.
□ Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и решения задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.
ПРИМЕЧАНИЕ
Согласно стандарту ISO 12207, модель жизненного цикла — это структура, содержащая процессы, действия и задачи, которые выполняются (решаются) в ходе разработки, функционирования и сопровождения программного продукта в течение всей жизни системы, от определения требований до завершения ее использования.
□ Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Мно-жество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.
ПРИМЕЧАНИЕ
Согласно ISO 12207, добавление уникальных или специфических процессов, действий и задач должно быть оговорено в контракте между сторонами. Причем «контракт» понимается в самом широком смысле — от юридически оформленного документа до неформального соглашения. Это соглашение может быть определено даже единственной стороной — как задача, поставленная самому себе.
□ Стандарт принципиально не содержит описания конкретных методов действий, а тем более заготовок решений или документации. Он лишь описывает архитектуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как предоставлять услуги или решать задачи, включенные в процессы. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.
□ Качество обеспечивается с помощью различных процессов, выполняемых с разной степенью независимости контролирующей деятельности, вплоть до обязательных требований к полной независимости проверяющего персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM, контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие пожеланиям потребителя.
□ Степень обязательности рассматриваемого стандарта следующая: после решения организации о соответствии торговых отношений стандарту ISO 12207 в качестве условия оговаривается ее ответственность за минимальный набор процессов и задач, которые обеспечивают согласованность с этим стандартом.
□ Стандарт содержит предельно мало описаний, направленных на проектирование базы данных. Это можно считать оправданным, так как разные системы и разные прикладные комплексы программного обеспечения могут не только использовать весьма специфические типы баз данных, но и вообще обходиться без них.
Ценность стандарта ISO 12207 в том, что в нем представлены наборы задач, харак-теристики качества, критерии оценки и т. п., обеспечивающие всесторонний охват проектных ситуаций. Например, при анализе требований к системе предусматри-вается, что:
□ рассматривается область применения системы для определения требований, предъявляемых к системе;
□ спецификация требований системы должна описывать функции и возможности системы, области применения системы, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования.
Далее, при анализе требований к программному обеспечению предусмотрено 11 характеристик качества, позволяющих обеспечить заданный уровень качества.
При этом разработчик должен установить и документировать в виде требований к программному обеспечению следующие спецификации и характеристики:
□ функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица про-граммного обеспечения должна быть выполнена;
□ внешние связи (интерфейсы) с единицей программного обеспечения;
□ квалификационные требования;
□ спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и веро-ятностью травмы персонала;
□ спецификации защищенности, включая спецификации, связанные с компро-метацией точности информации;
□ человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в кон-центрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
□ определение данных и требований к базе данных;
□ установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
□ документацию пользователя;
□ требования к интерфейсу пользователя.
ПРИМЕЧАНИЕ
Согласно стандарту ISO 12207, квалификационные требования — это набор критериев, или условий, которые должны быть удовлетворены для того, чтобы квалифицировать программный продукт как подчиняющийся (удовлетворяющий условиям) его спецификациям и готовый для использования в целевой окружающей среде.
Хотя стандарт не предписывает конкретной модели жизненного цикла или метода разработки, он определяет, что стороны-участники при использовании стандарта ответственны:
□ за выбор модели жизненного цикла для разрабатываемого проекта;
□ за адаптацию процессов и задач стандарта к этой модели;
□ за выбор и применение методов разработки программного обеспечения;
□ за выполнение действий и решение задач, подходящих для проекта программного обеспечения.
Билет 46.
Универсальный язык моделирования
Универсальный язык моделирования (UML), разработка которого началась с се-редины 90-х годов прошлого века на базе нескольких объектно-ориентированных методов и нотаций описания информационных систем, в настоящее время является общепринятым стандартом документирования процесса создания информационных систем и программного обеспечения. В качестве стандарта UML принят консорциумом OMG, в который входят все ведущие производители программного обеспечения.
Наиболее весомый вклад в разработку языка внесли известные специалисты Грэ-ди Буч (Grady Booch), Джим Румбах (Jim Rumbaugh) и Ивар Якобсон (Ivar Jacob-son); за счет объединения методик каждого из них, собственно, и возник язык UML.
Язык UML постоянно совершенствуется. В настоящее время текущей спецификацией языка является версия 2.0. Кроме того, сам язык предоставляет пользователю возможности расширения ядра языка для нужд конкретного производителя, хотя это и не рекомендуется делать по причине достаточности возможностей языка.
Первоначально язык UML создавался, чтобы упростить описание информационных систем на базе объектно-ориентированной технологии. Сейчас средствами языка можно описывать также программное обеспечение, оперирующее в основном потоками данных и методами их обработки (процедурное, алгоритмическое проектирование).
Предшественники UML
Причиной, побудившей к созданию универсального языка описания программного обеспечения, явилась постоянно возрастающая сложность проектируемых ин-формационных систем, которая, в свою очередь, диктуется усложнением решаемых задач.
Когда количество объектов информационной системы не превышает 6-8 (то есть психологического критерия, до которого человек еще способен оперировать ин-формацией без записи и дополнительной тренировки), сложности, возникающие при проектировании системы, преодолимы и без специальных средств. Такую информационную систему (для одного рабочего места, для небольшой компании) способен создать один человек. Когда же число объектов достигает тысяч и десятков тысяч, а число состояний и переходов между ними — миллионов, ни один специалист, каким бы образованным и опытным он ни был, не способен охватить систему в целом. К примеру, система навигации должна размещаться на тысячах автомобилей, морских и речных судах, железнодорожных составах, десятках искусственных спутников Земли, использовать тысячи компьютеров и всевозможных сетей связи.
Такие информационные системы под силу создавать только группам разработчиков, как правило, с разделением обязанностей на аналитиков, проектировщиков, программистов, тестеров и, конечно, руководителей. А там, где трудится коллектив, просто необходим понятный всем инструмент общения. Для инженеров-механиков таким инструментом, понятным как его коллегам, так и простым рабочим, являются машиностроительные чертежи, для строителей — всевозможные эскизы, планы и т. д., для инженеров-электронщиков — электрические схемы, топологические чертежи. Для программистов языком такого общения долгое время являлись алгоритмы и естественный человеческий язык. Каждый, кто хоть немного разбирается в программировании, понимает, что, за исключением очень простых примеров, без пояснений практически невозможно разобраться в коде программ, написанных не им самим, а часто и им самим, но давно.
Диаграммы на языке UML можно назвать «иллюстрациями к программному коду».
Создание диаграмм аналогично созданию проекта в строительстве — можно обойтись и без него, например, при строительстве сарая на дачном участке, однако чем больше здание, тем труднее это делать и тем неопределеннее конечный результат. Информационная система, описанная UML-диаграммами, показывает разработчику результат, который необходимо достичь в процессе проектирования.
Проблема коммуникации внутри коллектива разработчиков, требующая докумен-тирования результатов проектирования, чтобы иметь возможность в дальнейшем вносить в систему усовершенствования, является не единственной побудительной причиной создания UML.
Абсолютное большинство информационных систем, используемых в наши дни, в той или иной степени опираются на объектно-ориентированную технологию. Ключевой в эффективности таких информационных систем является удачно построенная иерархия объектов, позволяющая использовать преимущества объект-но-ориентированной технологии, включая инкапсуляцию, наследование и поли-морфизм (подробнее об объектно-ориентированной разработке информационных систем см. далее в этой книге).
Выявление объектов-сущностей, их свойств, построение их иерархии является в большинстве случаев нетривиальной задачей, которая решается методами объек-тно-ориентированного анализа.
Иерархия объектов должна отражать закономерности функционирования предметной области, то есть области деятельности человека, для которой создается информа-ционная система. Прямолинейное проектирование, как правило, не является опти-мальным. Из практики известно, что самыми удачными решениями являются системы, авторам которых удалось найти «изящную» комбинацию, неординарный ход, «изюминку» в построении иерархии объектов информационной системы.
Построение иерархии объектов требует опыта и усердной работы аналитиков и си-стемных проектировщиков, для облегчения интеллектуального труда которых весьма кстати пришлись возможности нотации (лат. notatio — обозначение, система записи), позволяющей легко и понятно фиксировать возникающие идеи. Этой цели служат всевозможные кружочки, квадратики, стрелки и линии, с помощью которых человек пытается зафиксировать свои мысли на листе бумаги или в электронном документе. С появлением соответствующих методик, а впоследствии и UML такая запись становится стандартизированной и понятной другим людям.
ПРИМЕЧАНИЕ
Проблемой, ставящей под угрозу осуществление крупного проекта, является уход из команды разработчиков одного или нескольких ведущих специалистов. Использова-ние стандарта документирования процесса разработки минимизирует риски срыва работы над проектом в таких случаях.
Универсальный язык моделирования возник не на пустом месте. С середины вось-мидесятых годов ведутся разработки методик, позволяющих автоматизировать процесс построения иерархий объектов. Некоторые из методик, например CRC-карточки, не потеряли своей актуальности.
Словарь предметной области
В словарь предметной области включаются термины, используемые специалистами, для которых разрабатывается система. Словарь создается с целью наиболее полного понимания поставленных задач проектировщиками, которые, как правило, специалистами в этой области не являются.
Словарь представляет собой список терминов с их краткой расшифровкой. По мере работы над системой словарь предметной области может дополняться. Составлением словаря занимаются те из проектировщиков и аналитиков, кто имеет непо-средственный контакт с конечными пользователями.
Использование в работе такого словаря весьма полезно и эффективно при решении практически любых задач.
Диаграммы сущность-связь
Построение диаграмм сущность-связь основано на выявлении форм взаимосвязи и взаимодействия сущностей. Подробнее эти диаграммы описаны в главе 6 на примере проектирования структуры базы данных.
Метод Аббота
Метод Аббота заключается в описании задачи на простом человеческом языке и анализе полученного текста. Существительные в этом случае принимаются как вероятные кандидаты на роль объектов-сущностей, а глаголы — на методы этих сущностей.
Метод Аббота поддается автоматизации, в частности соответствующие системы были построены Токийским технологическим институтом и фирмой Фуджи.
CRC-карточки
Аббревиатура CRC означает Class-Responsibilities-Collaborators (класс-ответствен-ность-участники). CRC-карточки впервые предложили Кент Бек (Kent Beck) и Уорд Каннингхэм (Ward Cunningham) для обучения объектно-ориентированному программированию.
CRC-карточки представляют собой обычные картонные карточки размером 10 на 15 сантиметров, на которых карандашом сверху пишется название класса, слева — за что он отвечает, справа — с какими классами он взаимодействует (сотрудничает, обменивается сообщениями).
В ходе анализа появляются новые карточки, в старые вносятся изменения. Может возникнуть ситуация, когда один из классов (объектов) окажется слишком большим, и на стадии реализации системы это приведет к необходимости его постоянного использования. В этом случае целесообразно разбить его на несколько классов или передать часть его функций другому классу.
ПРИМЕЧАНИЕ
Возможна ситуация, когда одни и те же сообщения будут передаваться между разными классами. Можно выделить такие сообщения в отдельный класс для удобства отладки и внесения изменений. Так поступают, например, при обращениях к базе данных с помощью SQL-запросов, выделяя транзакции в отдельный класс.
Карточки раскладываются в разном порядке, что помогает определить возможные варианты наследования свойств и методов, движения потоков данных.
Метод Буча
Метод Буча стал основой UML. Предложенная Бучем графическая нотация доста-точно распространена и наряду с UML используется в системах автоматизации про-цесса разработки программного обеспечения, в частности в системе Rational Rose.
Применяемые в методе Буча обозначения несколько отличаются от обозначений, принятых в UML. Так, класс в нотации UML представляет собой прямоугольник, в нотации Буча — облако, каким его рисуют дети, что по замыслу автора символизирует абстрактность этого понятия. Кроме того, язык UML более формализован за счет метамодели языка.
Билет 47.
Структура UML
В структуре универсального языка моделирования выделяют две основные состав-ляющие:
□ метамодель;
□ правила построения диаграмм.
Метамодель представляет собой описание общей структуры языка, основных понятий объектно-ориентированного проектирования (класс, объект, событие, ассоциация, автомат, наследование и пр.), а также методов расширения ядра UML. Описания используемых терминов в общем совпадают с определениями, приводимыми в этой книге, поэтому мы не будем подробно на них останавливаться.
ПРИМЕЧАНИЕ
Описание метамодели приводится на естественном человеческом языке с применением конструкций самого языка UML, что однако не создает трудностей при ее изучении.
Наличие метамодели придает языку UML строгость и выгодно отличает его от других методик.
Основной интерес для проектировщика представляют правила построения UML-диаграмм, основными разновидностями которых являются диаграммы:
□ прецедентов, или вариантов использования (use case diagram);
□ классов (class diagram);
□ состояний (statechart diagram);
□ активности, или деятельности (activity diagram);
□ взаимодействия (interaction diagrams), к которым относятся диаграммы после-довательности (sequence diagram) и кооперации, или сотрудничества (collaboration diagram);
□ компонентов (component diagram);
□ развертывания (deployment diagram).
Именно диаграммы в нотации UML служат удобным средством передачи информации об особенностях построения информационной системы между участниками проекта. Часто задание на проектирование рядовому программисту представляется именно в виде набора UML-диаграмм.
ПРИМЕЧАНИЕ
Юридически к категории программы для ЭВМ относятся не только код на каком-либо языке программирования и исполняемый машинный код, но и все материалы, полученные в ходе разработки программ, в первую очередь, это касается документированных решений, применяемых при проектировании системы и написанных как на естественном человеческом языке, так и на языке UML. Это еще один аргумент в пользу активного использования UML при разработках информационных систем, так как в случае возникновения спора UML-диаграммы могут стать удобными доказательствами необходимого по закону признака оригинальности программы для ЭВМ.
При проектировании информационной системы, как правило, составляется множество диаграмм одного и того же вида: множество диаграмм прецедентов, несколько диаграмм классов, множество диаграмм активности.
Необязательно всегда составлять все диаграммы. Язык UML создан для облегчения процесса разработки, а не для утомительного документирования всех шагов разработки. Некоторые из диаграмм могут отсутствовать.
Последовательность построения диаграмм также свободна.
Среди всех диаграмм следует выделить диаграмму классов, так как на ее основе возможна автоматическая генерация части программного кода будущей информа-ционной системы с описаниями классов и объектов (предварительное объявление в разделе типов и переменных), а также заголовки методов объектов, реализацию которых необходимо писать вручную. То же можно сказать в отношении диаграмм последовательности и кооперации, которые являются взаимно обратимыми, то есть их можно автоматически преобразовать друг в друга. Такие возможности предоставляют системы автоматизированного проектирования, наиболее удачной и известной из которых является система Rational Rose фирмы Rational Software.
Билет 48.
Диаграмма прецедентов
Диаграмма прецедентов служит для выявления и формального представления требований заказчика к проектируемой системе, то есть она описывает, какие возможности будет предоставлять система конечному пользователю, какая информация необходима для обработки запроса пользователя. При этом механизм функционирования системы от пользователя скрыт и на диаграмме прецедентов не показывается.
Конечный пользователь, в роли которого может выступать человек (например, покупатель или оператор) или техническое устройство (например, мобильный телефон), изображается в виде стилизованной фигурки человека.
Если же в качестве пользователя выступает сама система, что возможно, например, при предоставлении каких-либо функций определенному классу, вместо пользователя рекомендуется применять соответствующее обозначение класса.
Пользователь задействует систему определенным образом. Соответствующий прецедент (вариант использования) обозначается на диаграмме овалом, внутри которого пишется наименование варианта использования.
Для пояснения содержания диаграмм используют примечания, обозначаемые на диаграммах в виде листа бумаги с загнутым углом.
Текст примечания записывается внутри этого листа. Примечание соединяется пунктирной линией с тем элементом диаграммы, к которому оно относится.
Ниже перечислены определенные в нотации UML виды отношений между компо-нентами на диаграммах прецедентов.
□ Отношение ассоциации (association relationship) устанавливает роль пользователя в системе. Обозначается сплошной линией между пользователем и прецедентом (рис. 3.5, а).
□ Отношение расширения (extend relationship) определяет взаимосвязь прецедента с прецедентом, возможности которого он может использовать. Графически обозначается пунктирной стрелкой с пометкой «extend» от дополняющего пре-цедента к расширяемому. Случай, изображенный на рис. 3.5, б, говорит, что при определенных условиях прецедент В может быть дополнен прецедентом А. На практике это может означать, например, дополнительные (помимо обычных) меры по идентификации личности человека.
□ Отношение обобщения (generalization relationship) показывает, что компонент (пользователь или прецедент) является частным случаем другого компонента. Графически обозначается непрерывной стрелкой от общего к частному (рис. 3.5, в).
□ Отношение включения (include relationship) указывает на включение прецедента в другой прецедент в качестве его составной части. Один и тот же прецедент может быть включен в несколько более крупных прецедентов. Графически данное отношение обозначается пунктирной линией со стрелкой, направленной от базового прецедента к включаемому с пометкой «include» (рис. 3.5, г).
Цифры над стрелкой (см. рис. 3.5, а) обозначают кратность (multiplicity) отношения и показывают количество возможных компонентов данного отношения. Случай на рисунке означает, что один и тот же пользователь может задействовать систему данным образом любое количество (обозначается звездочкой) раз.
Бланк направлений на анализы
Л
Дежурный врач
Л
Медсестра
Проиллюстрируем изложенное на примере действий дежурного врача при по-ступлении пациента в больницу через приемный покой. Дежурный врач организует прием пациента, что подразумевает оформление истории болезни, проведение анализов, первичный осмотр, оповещает родственников пострадавшего. В случае тяжелого состояния пациента он направляется в реанимацию. Если состояние пациента безнадежно, от родственников испрашивается согласие на трансплантацию органов. Разрабатываемая информационная система должна автоматизировать выдачу направлений на анализы, предоставляя пакет документов для оформления согласия родственников. Истории болезни в организации ведутся в бумажной форме (результаты анализов в историю болезни вклеиваются). На рис. 3.6 представлен возможный вариант диаграммы прецедентов для данного случая.
Билет 49.
Пакеты
Для сложных систем возникает необходимость разбиения их на несколько состав-ляющих, причем таким образом, чтобы это разбиение отражалось в обозначении компонентов. Для этих целей в языке UML служат пакеты.
Компоненты, относящиеся к определенному пакету, могут быть доступны вне пакета, если указать имя компонента и его принадлежность определенному пакету через двойное двоеточие, например: Иня_Пакета::Имя_Компонента
Дата добавления: 2015-08-29; просмотров: 22 | Нарушение авторских прав
| <== предыдущая лекция | | | следующая лекция ==> |