Составление таблицы сравнительная характеристика современных операционных систем. Linux и Windows: сравнительная характеристика. Операционные системы семейства Linux

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

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

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

Объектная модель представляет статистическую структуру проек­тируемой системы (подсистемы). Однако знания статической структуры недостаточно, чтобы понять и оценить роботу под­системы. Необходимо иметь средства для описания изменений, которые происходят с объектами и их связями во время роботы подсистемы.

Одним из таких средств является динамическая модель под­системы. Она строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена. Динамическая модель подсистемы состоит из диаграмм сос­тояний ее объектов подсистем.

Текущее состояние объекта характеризуется совокупностью текущих значений его атрибутов и связей. Во время работы системы составляющие её объекты взаимодействуют друг с другом, в результате чего изменяются их состояния. Единицей влияния является событие : каждое событие приводит к смене состояния одного или нескольких объектов в системе, либо к возникновению новых событий. Работа системы характеризуется последовательностью происходящих в ней событий.

Событие происходит в некоторый момент времени. Примеры событий: старт ракеты, старт забега на 100 м, начало проводки, выдача денег и т.п. Событие не имеет продолжительности (точнее, оно занимает пренебрежимо малое время).

Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent ). Такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности.

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

При возникновении события происходит не только переход объекта в новое состояние, но и выполняется действие, связанное с этим событием. Действием называется мгновенная операция, связанная с событием.

Процесс построения объектной модели включает в себя следующие этапы:

Определение объектов и классов;

Подготовка словаря данных:

Определение зависимостей между объектами;

Определение свойств объектов и связей;

Организация и упрощение классов при использовании наследования;

Дальнейшее исследования и усовершенствование модели.

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

РАБОТА ВЫПОЛНЯЕТСЯ в StarUML

Время выполнения:

2 – 3 занятия

К защите работы должен быть предоставлен проект, созданный в пакете Rational Rose, включающий три вида диаграмм: прецедентов, классов (интерфейс, данные) и последовательностей для каждой функции.

ПРИМЕР ЗАДАНИЯ:

Необходимо обеспечить хранение в базе данных следующей информации:

- информация о студентах

o Ф.И.О.,

o адрес,

o паспортные данные,

o номер зачетки,

o дата рождения,

o группа);

- информация о специальностях

o наименование специальности,

o шифр;

- информация о группах

o специальность,

o год поступления,

o номер группы.

Обеспечить выдачу документа “Список группы”, содержащего поля:

· порядковый номер,

· Ф.И.О.,

· номер зачетки.

Порядок выполнения работы

Построение объектной модели выполняется в пакете Rational Rose. Для этого создадим пустой проект. Начинать выполнение работы следует с диаграммы прецедентов. Ее строят в области Main секции Use Case View, как показано на рис.9.

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

Построенная диаграмма изображена на рис. 10.

Далее в секции Logical View следует создать две диаграммы классов. Для этого можно создать два пакета. Первая диаграмма должна содержать классы интерфейса проектируемого приложения (см. рис. 11). На данном рисунке в классах «Список групп» и «Список студентов» опущены операции добавления, изменения и удаления во избежание загромождения рисунка. Список группы (нижний класс) является выходным документом (перед ним следует класс «Выбор группы», т.к. необходимо получить список студентов определенной группы). Вторая диаграмма – сущности базы данных (см. рис. 12).

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

Следует проставить ключевые поля и установить связь (из контекстного меню стрелки - Multiplicity).

Следующий этап построения объектной модели – создание диаграмм последовательностей. Диаграммы последовательностей создаются для каждого прецедента на диаграмме прецедентов. Чтобы добавить диаграмму последовательностей к прецеденту необходимо выбрать его в дереве и вызвать на нем контекстное меню (NewàSequence Diagram) как показано на рис. 13.

Пример диаграммы последовательностей для прецедента «Ведение списка специальностей» представлен на рис. 14.

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

Объектная модель

Объектно-ориентированная технология основывается на так называемой объектной модели. Основными принципами ее построения являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности.

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

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

. (object-oriented analysis, ООА) направлен на создание моделей реальной действительности на основе объектно-ориентированного мировоззрения.

Объектно-ориентированный анализ - это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области.

. (object-oriented design, ООД)

Программирование прежде всего подразумевает правильное и эффективное использование механизмов конкретных языков программирования. Проектирование, напротив, основное внимание уделяет правильному и эффективному структурированию сложных систем. Определим объектно-ориентированное проектирование следующим образом:

Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы.

В данном определении содержатся две важные части: объектно-ориентированное проектирование

1) основывается на объектно-ориентированной декомпозиции;

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

Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного, в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами.

. (object-oriented programming, OOП)

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

В данном определении можно выделить три части:

1) OOП использует в качестве базовых элементов объекты, а не алгоритмы;

2) каждый объект является экземпляром какого-либо определенного класса;

3) классы организованы иерархически .

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

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

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

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

• абстрагирование;
• инкапсуляция;
• модульность;
• иерархия.

Эти элементы являются главными в том смысле, что без любого из них модель не будет объектно-ориентированной. Кроме главных, имеются еще три дополнительных элемента:

• типизация;
• параллелизм;
• сохраняемость.

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

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

Абстракция основывается на понятиях клиента и сервера.

Клиентом называется любой объект, использующий ресурсы другого объекта (называемого сервером ).

Мы будем характеризовать поведение объекта услугами, которые он оказывает другим объектам, и операциями, которые он выполняет над другими объектами. Такой подход концентрирует внимание на внешних проявлениях объекта и приводит к идее контрактной модели программирования, когда внешнее проявление объекта рассматривается с точки зрения его контракта с другими объектами, в соответствии с этим должно быть выполнено и его внутреннее устройство (часто во взаимодействии с другими объектами). Контракт фиксирует все обязательства, которые объект-сервер имеет перед объектом-клиентом. Другими словами, этот контракт определяет ответственность объекта, то есть то поведение, за которое он отвечает.

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

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

Абстракция и инкапсуляция дополняют друг друга: абстрагирование направлено на наблюдаемое поведение объекта, а инкапсуляция занимается внутренним устройством. Чаще всего инкапсуляция выполняется посредством скрытия информации, то есть маскировкой всех внутренних деталей, не влияющих на внешнее поведение. Обычно скрываются и внутренняя структура объекта, и реализация его методов. Практически это означает наличие двух частей в классе: интерфейса и реализации. Интерфейс отражает внешнее поведение объекта, описывая абстракцию поведения всех объектов данного класса. Внутренняя реализация описывает представление этой абстракции и механизмы достижения желаемого поведения объекта. Принцип разделения интерфейса и реализации соответствует сути вещей: в интерфейсной части собрано все, что касается взаимодействия данного объекта с любыми другими объектами; реализация скрывает от других объектов все детали, не имеющие отношения к процессу взаимодействия объектов.

Модульность - это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули.

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

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

Иерархия - это упорядочение абстракций, расположение их по уровням.

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия "is-a") и структура объектов (иерархия "part of").

Важным элементом объектно-ориентированных систем и основным видом иерархии "is-a" является упоминавшаяся выше концепция наследования. Наследование означает такое отношение между классами (отношение родитель/потомок), когда один класс заимствует структурную или функциональную часть одного или нескольких других классов (соответственно, одиночное и множественное наследование ). Иными словами, наследование создает такую иерархию абстракций, в которой подклассы наследуют строение от одного или нескольких суперклассов. Часто подкласс достраивает или переписывает компоненты вышестоящего класса.

Если иерархия "is а" определяет отношение "обобщение/специализация", то отношение "part of" (часть) вводит иерархию агрегации. В иерархии "part of" класс находится на более высоком уровне абстракции, чем любой из использовавшихся при его реализации.

Типизация - это способ защититься от использования объектов одного класса вместо другого, или по крайней мере управлять таким использованием.

Параллелизм - это свойство, отличающее активные объекты от пассивных.

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

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

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

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

Преимущества объектной модели

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

1. Объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных словно программирование. Страуструп отмечает: "Не всегда очевидно, как в полной мере использовать преимущества такого языка, как С++. Существенно повысить эффективность и качество кода можно просто за счет использования С++ в качестве "улучшившего С" с элементами абстракции данных. Однако намного более значительным достижением является введение иерархии классов в процессе проектирования. Именно это называется объектно-ориентированным проектированием и именно здесь преимущества С++ демонстрируются наилучшим образом". Опыт показал, что при использовании таких языков, как Smalltalk, Object Pascal, С++, CLOS и Аdа, вне объектной модели, их наиболее сильные бока или игнорируются, или применяются неправильно.
2. Использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что, в конечном итоге, ведет к созданию среды разработки. Объектно-ориентированные системы часто выходят более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта, за счет использования предыдущих разработок, которое дает выигрыш в стоимости и времени
3. Использование объектной модели приводит к построению систем на основе стабильных промежуточных описаний, что упрощает процесс внесения изменений. Это дает системе возможность развиваться постепенно и не приводит к полной ее переработке даже в случае существенных змей исходных требований.
4. Объектная модель уменьшает риск разработки сложных систем, в первую очередь потому, что процесс интеграции растягивается на все время разработки, а не превращается в одноразовое событие, Объектный подход состоит из ряда хорошо продуманных этапов проектирования, которое также уменьшает степень риска и повышает уверенность в правильности принятых решений.
5. Объектная модель ориентирована на человеческое восприятие мира, или, по словам Робсона, "много из людей, которые не имеют понятие о том, как работает компьютер, находят полностью естественным объектно-ориентированный подход к системам".