Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

В даній роботі створюється програма для імітації роботи віртуальної пам'яті. Створена програма дає змогу імітувати роботу віртуальної памяті. Реалізовані алгоритми FIFO, LNU, NFU. Розроблений 3 страница



2.2.2 Діаграми діяльності

Діаграма діяльності — в UML, візуальне представлення графу діяльностей. Граф діяльностей є різновидом графу станів скінченного автомату, вершинами якого є певні дії, а переходи відбуваються по завершенню дій.

Дія є фундаментальною одиницею визначення поведінки в специфікації. Дія отримує множину вхідних сигналів, та перетворює їх на множину вихідних сигналів. Одна із цих множин, або обидві водночас, можуть бути порожніми. Виконання дії відповідає виконанню окремої дії. Подібно до цього, виконання діяльності є виконанням окремої діяльності, буквально, включно із виконанням тих дій, що містяться в діяльності. Кожна дія в діяльності може виконуватись один, два, або більше разів під час одного виконання діяльності. Щонайменше, дії мають отримувати дані, перетворювати їх та тестувати, деякі дії можуть вимагати певної послідовності. Специфікація діяльності (на вищих рівнях сумісності) може дозволяти виконання декількох (логічних) потоків, та існування механізмів синхронізації для гарантування виконання дій у правильному порядку.

Діаграма діяльності входу в систему представлена на рис. 2.2.

 

Рисунок 2.2 – Діаграма діяльності системи

 

Спочатку слідує завантаження системи. Після цього, вказується розмір фізичної пам’яті та розмір сторінки пам’яті. Далі, необхідно додати сегменти. При додаванні сегменту вказується його ім’я, розмір та колір для візуалізації. Пілся цього, система відобразить доданий сегмент як завантажений у зовнішню пам’ять. Наступним кроком є безпосередня емуляція роботи віртуальної пам’яті, а саме емуляція звертання до сторінки. Якщо сторінка вже завантажена у фізичну пам’ять, то відбувається анімація звертання в залежності від типу доступу — запису чи читання. Якщо ж сторінка відсутня в даний момент у фізичній пам’яті, то потрібно її завантажити із зовнішньої пам’ятті. При цьому може виникнути проблема, коли у фізичній пам’яті немає вільного місця. В такому випадку потрібно застосувати алгоритм заміщення і витіснити одну із сторінок (яку саме, визначає безпосередньо алгоритм, тому різні алгоритми можуть витісняти різні сторінки). Якщо до сторінки звертались лише за читанням, то її можна переписати поточною, оскільки її точна копія є у зовнішній пам’яті. Якщо ж сторінка була модифікована записом, то її потрібно записати у зовнішню пам’ять. Після вищезазначених операцій відбувається емуляція доступу до сторінки шляхом анімації.



2.2.3 Діаграма станів

Діаграма станів — спрямований граф, вершинам якого відповідають стани автомата, а дугам — вхідні сигнали. Якщо вхідний сигнал xi спричиняє перехід автомата зі стану aj в стан ak, то на графі цьому факту відповідає дуга, позначена символом xi, яка з’єднує вершину aj з ak. Такий граф задає функцію переходів автомата. Для визначення функції виходів, дуги цього графа позначаються ще й відповідними вихідними сигналами. Визначення автомата за допомогою його графа є особливо наочним за умов невеликої кількості станів.

Діаграми станів Хареля стають дедалі популярнішими після того, як варіант цих діаграм став частиною Unified Modeling Language. Цей вид діаграм дозволяє моделювання надстанів, ортогональних регіонів, та діяльності як складової стану.

Класичні діаграми станів вимагають створення окремих вершин для кожної допустимої комбінації параметрів, що визначають стан. Це може призводити до необхідності введення великої кількості вершин та переходів між ними для систем складніших за найпростіші. Така складність ускладнює перегляд та розуміння діаграми. Діаграми Хареля дозволяють моделювання багатьох автоматів з перетином функцій на одній діаграмі. Кожен з відокремлених автоматів може виконувати внутрішні переходи не впливаючи на інші автомати на діаграмі. Стан кожного з відокремленого автомата на діаграмі визначає стан системи. Діаграма Хареля еквівалентна діаграмі станів але полегшує перегляд та розуміння отриманих діаграм.

Діаграма станів системи представлена на рис. 2.4.

 

 

Рисунок 2.4 – Діаграма станів системи

 

Першим кроком є встановлення стартових параметрів системи, а саме розміру фізичної пам’яті та розміру сторінки пам’яті. Цей стан є першочерговим, оскільки в послідуючих кроках, система в розрахунках опирається на ці параметри.

Основним станом системи є безпосередня емуляція роботи віртуальної пам’яті. Він включає в себе ряд підстанів, а саме додавання нового сегменту із послідуючим його завантаженням у фізичну пам’ять, а також звертання до сторінки.

 

 

2.3 Висновки

В даному розділі були проаналізовані вимоги до розроблюваної системи. Вимоги відображають те, що система повинна робити.

Спочатку були сформульовані первинні вимоги, що документують бажання і потреби вимог замовника і фактично відображають функції проектованої системи на концептуальному рівні.Це є лише початковою фазою роботи з вимогами.

Наступним кроком стало виділення детальних вимог, що документують вимоги спеціально структурованою мовою за допомогою. Вони деталізують первинні вимоги.

Результати процедур із формулювання та аналізу вимог представлені у вигляді діаграми прецедентів (варіантів використання, UseCase), діаграми діяльності, діаграми взаємодій (діаграми послідовностей і комунікації) та їх описів.


 

3 ПРОЕКТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ СТВОРЕННЯ ЗАСОБІВ ОПИСУ ПРОГРАМИ ДЛЯ ПОБУДОВИ ЇЇ АВТОМАТНОЇ МОДЕЛІ

Проектування є процесом специфікації рішення, яке суміщене з моделлю аналізу.

Під час проектування програмної системи використано прототипо–орієнтований стиль проектування. Розробник практично автономно розробляє виконавчу модель системи. При цьому використовується модель предметної області. Цей стиль характерний тим, що в ньому основною дійовою особою є програміст, що добре володіє певним набором ІТ–технологій, але слабо орієнтується в алгоритмах рішення завдань і можливих конструкціях системи. Характерною рисою цього стилю є ілюзія швидкого просування у вирішенні проблеми. Такий стиль з успіхом застосовується невеликими командами під час проектування систем невеликого об’єму.

Розглянемо кожен з етапів проектування системи.

3.1 Архітектурне проектування

Архітектурне проектування — це розроблення компонентів третього рівня, визначення вхідних і вихідних даних рівнів ієрархії компонентів і їхніх зв’язків. Результат проектування — архітектура й інфраструктура, що містять у собі набір об’єктів, з яких можна формувати деякий конкретний вид архітектурної схеми для конкретного середовища виконання системи, а також набір елементів керування і контролю. Проектування архітектури системи завершується створенням опису, в якому відображені зафіксовані проектні рішення, логічна і фізична структура системи, а також способи взаємодії об’єктів.

3.1.1 Об’єктно орієнтована парадигма

Найважливішим кроком на шляху до вдосконалення мов програмування стала поява об’єктно–орієнтованого підходу до програмування (або, скорочено, ООП) та відповідного класу мов.

При об’єктно–орієнтованому підході програма являє собою опис об’єктів, їх властивостей (або атрибутів), сукупностей (або класів), відносин між ними, способи їх взаємодії та операцій надоб’єктами (або методи).

Безперечною перевагою даного підходу є концептуальна близькість до предметної області довільної структури та призначення. Механізм спадкоємства атрибутів і методів дозволяє будувати похідні поняття на основі базових і таким чином створювати модель як завгодно складної предметної області з заданими властивостями.

Ще одним теоретично цікавою і практично важливою властивістю об’єктно–орієнтованого підходу є підтримка механізму обробки подій, які змінюють атрибути об’єктів і моделюють їх взаємодію в предметній області.

Переміщаючись по ієрархії класів від загальних понять предметної області до більш конкретних (або від більш складних – до більш простих) і навпаки, програміст отримує можливість змінювати ступінь абстрактності або конкретності погляду на модельований їм реальний світ.

Використання раніше розроблених (можливо, іншими колективами програмістів) бібліотек об’єктів і методів дозволяє значно заощадити трудовитрати при виробництві програмного забезпечення, особливо, типового.

Об’єкти, класи і методи можуть бути поліморфними, що робить реалізоване програмне забезпечення більш гнучким і універсальним.

Складність адекватної (несуперечливої і повної) формалізації об’єктної теорії породжує труднощі тестування та верифікації створеного програмного забезпечення. Мабуть, ця обставина є одним з найбільш істотних недоліків об’єктно–орієнтованого підходу до програмування.

Найбільш відомим прикладом об’єктно–орієнтованої мови програмування є мова C + +, яка розвинулася з імперативної мови С. Його прямим нащадком і логічним продовженням є мова С #. Інші приклади об’єктно–орієнтованих мов програмування: Visual Basic, Java, Eiffel, Oberon.

Перехід від структурно–процедурного підходу до об’єктно–орієнтованого програмування, подібно переходу від низькорівневих мов програмування до мов високого рівня, вимагає значних витрат на навчання. Природно, що платою за це є підвищення продуктивності праці програмістів при проектуванні та реалізації програмного забезпечення. Інша перевага ООП перед імперативним підходом – більш високий відсоток повторного використання вже розробленого програмного коду.

При цьому, на відміну від попередніх підходів до програмування, об’єктно–орієнтований підхід вимагає глибокого розуміння основних принципів, або, інакше, концепцій, на яких він базується. До числа основоположних понять ООП зазвичай відносять абстракцію даних, успадкування, інкапсуляцію і поліморфізм.

Спадкування конкретних атрибутів об’єктів і функцій оперування об’єктами засноване на ієрархії. Інкапсуляція означає "приховування" властивостей і методів всередині об’єкта. Поліморфізм, як і у функціональному програмуванні, розуміється як наявність функцій з можливістю обробки даних змінного типу.

У розділах математики, які досліджують моделювання процесу створення програм, під абстракцією прийнято розуміти довільне вираження мови програмування, яке є відмінним від ідентифікатора.

Найважливішою операцією є операція обчислення значення виразу або команди, тобто операція означування (зокрема, функція обчислення значення явно використовувалася при побудові семантики мови програмування). У цьому зв’язку важливо встановити, що є значенням абстракції. Будемо вважати, що значення функції або змінної може бути присвоєно абстракції і є значенням останньої.

В об’єктно–орієнтованому програмуванні кожен об’єкт представляє собою принципово динамічну сутність, тобто змінюється в залежності від часу (а також від впливу зовнішніх по відношенню до нього факторів). Інакше кажучи, об’єкт володіє тим чи іншим способом поведінки. У відношенні абстракції як об’єкта, поведінка полягає у додатку функції до аргументу.

Як було сказано, концепція абстракції в об’єктно–орієнтованому програмуванні адекватно моделюється за допомогою ламбда–числення. Точніше кажучи, операція абстракції в повній мірі є моделлю однойменного поняття ООП.

Іншою фундаментально складовою концепцією об’єктно–орієнтованого програмування є інтуїтивно ясне поняття наслідування. У неформальній постановці під наслідуванням розуміється властивість того чи іншого об’єкта, який є похідним від якогось базового, зберігати поведінка (а саме, атрибути та операції над ними), характерне для батьківського об’кта. З точки зору мов програмування поняття спадкування означає застосовність всіх або лише деяких властивостей або методів базового (або батьківського) класу для всіх класів, похідних від нього. Крім того, збереження властивостей та методів базового класу має забезпечуватися і для всіх конкретизацій (тобто конкретних об’єктів) будь–якого похідного класу. У математиці концепцію успадкування прийнято моделювати, наприклад, ставленням часткового порядку (яке представляє собою вид ієрархії).

3.1.2 Структурна ієрархія системи

Розроблювана система згідно її опису виконує наступні функції:

- підтримка сучасних версій операційних систем сімейства Windows;

- установка значення розміру фізичної пам’яті при старті системи;

- визначення розміру сторінки пам’яті при запуску системи;

- можливість додавання сегментів пам’яті із довільним розміром (в тому числі розміром, що перевищує розмір фізичної пам’яті);

- вибір кольору сегменту для наочного представлення сегменту у віртуальній пам’яті;

- введення імені сегменту;

- візуальне представлення моделі віртуальної пам’яті;

- візуалізація завантаження сегменту у фізичну пам’ять;

- інтерактивна демонстрація емуляції звертання до сторінок у віртуальній пам’яті;

- реалізація як вибіркових звертань до сторінки сегменту із типом читання та запису, так і реалізація випадкових звертань;

- реалізація алгоритмів заміщення, додавання, витіснення.

Структурна ієрархія системи представлена на рис 3.1.

 

 

Рисунок 3.1 – Структурна ієрархія системи

3.1.3 Структурна схема системи

У процесі проектування відбулася декомпозиція системи на базові компоненти. Кожен з них містить в собі певний набір функцій і пов’язаний з іншими (рис. 3.2).

 

Рисунок 3.2 – Структурна схема системи

 

Центральним елементом системи є модуль ядра. Він є зв’язовуючою ланкою між іншими модулями системи. В ньому інкапсульована вся логіка системи. Також в даному модулі реалізований механізм подій, що дозволяє модулю графічного інтерфейсу підписуватись на них і таким чином адекватно реагувати на поведінку системи. Модуль ядра отримує на вході розмір фізичної пам’яті та сторінки пам’яті, після чого ініціює початкову ініціалізацію системи. В ньому реалізовані інтерфейсні методи для звертання із модулю графічного інтерфейсу. Також, в ньому знаходяться менеджер віртуальної пам’яті, абстракція фізичної та зовнішньої пам’яті, сторінки, сегменту. Також в модулі реалізовані базові класи для роботи з віртуальною пам’яттю, виконання запитів, виділення окремих потоків і асинхронна обробка відповідей після виконання запитів, оповіщення системи через механізм подій, бінарна сериалізація і десериалізація налаштувань програми. Ряд об’єктів в даному модулі є синглтон–об’єктами, тобто такими, що створюються в єдиному екземплярі.

Модуль графічного інтерфейсу є кінцевим модулем, що використовує модуль ядра, візуалізує його роботу, отримує команди а також виводить інформацію. Він реалізований у вигляді набору форм Windows, що містять логіку посилання повідомлень та обробку користувацьких подій, що визначені в модулі ядра. Кожна з форм містить набір візуальних та невізуальних компонент, таких як кнопки, поля вводу, таблиці, діаграми, тощо.

Модуль віджетів служить для візуалізації роботи віртуальної пам’яті. Він містить функціонал динамічного створення та знищення компонент, геометричні розрахунки для анімації, методи для анімування сторінок пам’яті та ряд інших важливих методів. Також модуль віджетів взаємодіє з такими механізмами операційної системи, як рендер, буферизація, маніпуляції з пам’яттю. Реалізований вигляді набору статичних класів.

Модуль алгоритмів заміщення призначений для підтримки таких алгоритмів у менеджері віртуальної пам’яті. Він включає базовий абстрактний клас, що містить загальний інтерфейс алгоритмів заміщення, а також конкретні реалізації таких алгоримтів. При ініціалізації менеджера віртуальної пам’яті, створюються екземпляри всіх алгоритмів, а користувач при роботі програми обирає необхідний, для візуалізацїї його роботи у віртуальній пам’яті.

3.2 Детальне проектування

3.2.1 Діаграма класів

Діаграма класів – статичне представлення структури моделі. Відображає статичні (декларативні) елементи, такі як: класи, типи даних, їх зміст та відношення.

Діаграма класів, також, може містити позначення для пакетів та може містити позначення для вкладених пакетів. Також, діаграма класів може містити позначення деяких елементів поведінки, однак їх динаміка розкривається в інших типах діаграм. Діаграма класів (class diagram) служить для представлення статичної структури моделі системи в термінології класів об’єктно–орієнтованого програмування. На цій діаграмі показують класи, інтерфейси, об’єкти й кооперації, а також їхні відносини.

Діаграма класів модуля ядра представлена на рис. 3.3.

 

 

Рисунок 3.3 – Діаграма класів модуля ядра

 

Центральним класом в модулі ядра є MemoryManager. Він є абстракцією менеджера віртуальної пам’яті. Даний клас є синглтон–об’єктом. До його стану включаються наступні поля:

1. Список сегментів. Являє собою масив екземплярів класу Segment. В ньому знаходяться всі сегмени — неактивні та завантажені.

2. Список активних сегментів. Містить завантажені в даний момент часу сегменти у фізичну пам’ять.

3. Список алгоритмів. Містить список екземплярів класу алгоритму.

4. Поточний алгоритм. Містить поточний екземпляр алгоритму, що використовується в стратегії заміщення в поточний момент. Може змінюватись в часі.

5. Менеджер фізичної пам’яті.

6. Менеджер зовнішньої пам’яті.

Клас Page інкапсулює абстракцію сторінки пам’яті. Містить поля, що вказують віртуальний номер в сегменті, безпосереднє посилання на сегмент, розмір, прапорці перебування у фізичній пам’яті, зміненого стану, звертання, що використовуються алгоритмами заміщення. Даний клас знаходиться внизу абстрактної ієрархії, та використовується класом сегменту. Також до екземплярів класу прив’язуються візуальні віджети, що потрібні для візуального представлення віртуальної пам’яті.

Клас Segmentмістить абстракцію сегменту пам’яті. Він включає контейнер об’єктів сторінок. Також містить такі поля, як ім’я, розмір, кількість сторінок та стан — завантажений він у фізичну пам’ять чи ні. Екземпляри даного класу створюються та зберігаються в менеджері віртуальної пам’яті.

Клас PhysicalMemoryє абстракцією фізичної пам’яті. Містить контейнер сторінок пам’яті, в тому числі вони можуть бути порожніми, що свідчить про вільні місця у віртуальній пам’яті. Містить такі операції, як пошук вільної сторінки для додавання сторінки, повернення дампу всієї фізичної пам’яті.

3.2.2 Діаграма послідовності

Діаграма послідовності — в UML, діаграма послідовності відображає взаємодії об’єктів впорядкованих за часом. Зокрема, такі діаграми відображають задіяні об’єкти та послідовність відправлених повідомлень.

Діаграма послідовності системи зображена на рис. 3.5.

 

Рисунок 3.5 – Діаграма послідовності системи

 

Початковою дією передача вхідних параметрів від графічного інтерфейсу до менеджеру віртуальної пам’яті, а саме розміру фізичної пам’яті та сторінки. Після цього, менеджер віртуальної пам’яті проводить внутрішню ініціалізацію системи. Наступною дією є додавання сегменту, що передається від графічного інтерфейсу до менеджеру віртуальної пам’яті. В свою чергу, менеджер формує необхідні дані, та передає їх менеджеру віджетів, що ініціює візуальне представлення операції та передає його назад графічному інтерфейсу. Аналогічно відбуваються операції завантаження сегменту у фізичну пам’ять та емуляція звертання до сторінки пам’яті.

3.3 Висновки

В даному розділі було проведено аналіз та вироблено рішення відповідно до моделі аналізу, яке оптимізує набір критеріїв проектування, які показують, як ця поведінка (робота) системи може бути реалізована.

Спочатку було сформовано архітектуру системи — перший і основний крок у вирішенні завдання проектування, що закладає фундамент уявлення програмної системи, здатної виконувати весь спектр детальних вимог. Тобто, було спроектовано систему на найвищому рівні (логічна архітектура). Логічна архітектура описує систему в термінах її принципової організації у вигляді пакетів, програмних класів і підсистем. Вона називається логічною, оскільки не визначає способи розгортання цих елементів у різних операційних системах.

Після цього, була розроблена детальна архітектура. Система була відображена шляхом опису процесу об’єктно–орієнтованої декомпозиції системи до рівня переліку підсистем та їх зв’язків, опису її логічної структури, класів та діаграми послідовності.

В результаті вищезазначених дій, було сформовано кінцевий набір модулів та класів.


 

4 КОНСТРУЮВАННЯ ТА ТЕСТУВАННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

4.1 Розробка інтерфейсу користувача

Інтерфейс користувача складається з трьох форм. Перша — форма входу в систему зображена на рис. 4.1.

 

 

Рисунок 4.1 – Форма входу в систему

 

Дана форма потрібна для введення вхідних даних системи, а саме розміру сторінки пам’яті та кількості сторінок фізичної пам’яті.

Друга форма системи є основною формою системи. Вона зображена на рис 4.2.

 

Рисунок 4.2 – Головна форма програми

 

Головна форма системи умовно поділена на чотири частини — робота з сегментами, емуляція роботи віртуальної пам’яті, візуалізація стану фізичної пам’яті та візуалізація стану зовнішньої пам’яті. Дві останні частини представляють собою анімовані елементи, для наочності операцій з віртуальною пам’яттю.

Третя форма, представляє собою діалогове вікно для додавання нового сегменту пам’яті в систему. Вона представлена на рис. 4.3.

 

 

 

Рисунок 4.3 – Форма додавання нового сегменту пам’яті

 

Наочність стану системи. Система інформує користувача про стан своєї роботи – тривалість процесів, наслідки застосування дій та інше. Результат дій користувача виводиться в окремому вікні. Поточна інформація про процес у вигляді повідомлення на панелі стану.

Відповідність системи реальному світові. Взаємодія із користувачем йде його мовою. Використання зрозумілих понять, образів та концепцій із знайомої реальної предметної області.

Управління системою та свобода дій користувачів. Реалізована можливість користувача управляти поточним станом системи, виправляти помилки, відміняти або повторювати дії. Якщо дію відмінити неможливо – виводиться відповідне повідомлення.

Гнучкість та ефективність використання. Інтерфейс однаково зручний і для новачків і для досвідчених користувачів. Функції, що прискорюють роботу, мають обмежену доступність

Естетичний і мінімалістський дизайн. Використано не більше 3–4 кольорів. Мінімальна кількість кнопок та текстових написів.

 

 

4.2 Кодування системи

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

4.2.1 Вибір мови програмування

У якості середовища програмування було вибрано Microsoft Visual Studio 2013 та мова програмування C#.

Microsoft Visual Studio — серія продуктів фірми Майкрософт, які включають інтегроване середовище розробки програмного забезпечення та ряд інших інструментальних засобів. Ці продукти дозволяють розробляти як консольні програми, так і програми з графічним інтерфейсом, в тому числі з підтримкою технології Windows Forms, а такожвеб–сайти, веб–застосунки, веб–служби як в рідному, так і в керованому кодах для всіх платформ, що підтримуються Microsoft Windows, Windows Mobile, Windows CE,.NET Framework,.NET Compact Framework та Microsoft Silverlight.

Visual Studio включає один або декілька з наступних компонентів:

Visual Basic.NET, а до його появи — Visual Basic;

Visual C++;

Visual C#;

Visual F# (входить до складу Visual Studio 2010);

Visual Studio Debugger;

Багато варіантів постачання також включають:

Microsoft SQL Server або MSDE Visual Source Safe — файл–серверна система управління версіями.

У минулому, до складу Visual Studio також входили продукти:

Visual InterDev;

Visual J++;

Visual J#;

Visual FoxPro;

Visual Source Safe – файл–серверна система управління версіями.

Microsoft.NET — програмна технологія, запропонована фірмою Microsoft як платформа для створення як звичайних програм, так і веб–застосунків. Багато в чому є продовженням ідей та принципів, покладених в технологію Java. Одною з ідей.NET є сумісність служб, написаних різними мовами. Хоча ця можливість рекламується Microsoft як перевага.NET, платформа Java має таку саму можливість.

Кожна бібліотека в.NET має свідчення про свою версію, що дозволяє усунути можливі конфлікти між різними версіями збірок.

.NET — крос–платформова технологія, в цей час існує реалізація для платформи Microsoft Windows, FreeBSD(від Microsoft) і варіант технології для ОС Linux в проекті Mono (в рамках угоди між Microsoft з Novell), Dot GNU.

Захист авторських прав відноситься до створення середовищ виконання (CLR — Common Language Runtime) для програм.NET. Компілятори для.NET випускаються багатьма фірмами для різних мов вільно.

Розробка Microsoft технології.NET Framework почалась у 1999 році. Офіційно про розробку нової технології було оголошено 13 січня 2000 року. В цей день керівництвом компанії була озвучена нова стратегія, яка отримала назву Next Generation Windows Services. Нова стратегія повинна була об’єднати у єдине вже існуючі і майбутні розробки Microsoft для надання можливості користувачам працювати з Всесвітньою павутиною з допомогою безпровідних пристроїв, що мають доступ в Інтернет, як зі стаціонарних комп’ютерів так і з інших пристроїв.

C# — об’єктно–орієнтована мова програмування з безпечною системою типізації для платформи.NET. Розроблена Андерсом Гейлсбергом, Скотом Вілтамутомта Пітером Гольде під егідою Microsoft Research (при фірмі Microsoft).

Синтаксис C# близький до С++ і Java. Мова має строгу статичну типізацію, підтримує поліморфізм, перевантаження операторів, вказівники на функції–члени класів, атрибути, події, властивості, винятки, коментарі у форматі XML Перейнявши багато що від своїх попередників мов С++, Delphi, Модула і Smalltalk — С#, спираючись на практику їхнього використання, виключає деякі моделі, що зарекомендували себе як проблематичні при розробці програмних систем, наприклад множинне спадкування класів (на відміну від C++).

C# є дуже близьким родичем мови програмування Java. Мова Java була створена компанією Sun Microsystems, коли глобальний розвиток інтернету поставив задачу розосереджених обчислень. Взявши за основу популярну мову C++, Java виключила з неї потенційно небезпечні речі (типу вказівників без контролю виходу за межі). Для розосереджених обчислень була створена концепція віртуальної машини та машинно–незалежного байт–коду, свого роду посередника між вихідним текстом програм і апаратними інструкціями комп’ютера чи іншого інтелектуального пристрою.

Java набула чималої популярності, і була ліцензована також і компанією Microsoft. Але з плином часу Sun почала винуватити Microsoft, що та при створенні свого клону Java робить її сумісною виключно з платформою Windows, чим суперечить самій концепції машинно–незалежного середовища виконання і порушує ліцензійну угоду. Microsoft відмовилася піти назустріч вимогам Sun, і тому з’ясування стосунків набуло статусу судового процесу. Суд визнав позицію Sun справедливою, і зобов’язав Microsoft відмовитися від поза ліцензійного використання Java.

У цій ситуації в Microsoft вирішили, користуючись своєю вагою на ринку, створити свій власний аналог Java, мови, в якій корпорація стане повновладним господарем. Ця новостворена мова отримала назву C#. Вона успадкувала від Java концепції віртуальної машини (середовище.NET), байт–коду (MSIL) і більшої безпеки вихідного коду програм, плюс врахувала досвід використання програм на Java.

Нововведенням C# стала можливість легшої взаємодії, порівняно з мовами–попередниками, з кодом програм, написаних на інших мовах, що є важливим при створенні великих проектів. Якщо програми на різних мовах виконуються на платформі.NET,.NET бере на себе клопіт щодо сумісності програм (тобто типів даних, за кінцевим рахунком).


Дата добавления: 2015-09-30; просмотров: 89 | Нарушение авторских прав







mybiblioteka.su - 2015-2024 год. (0.031 сек.)







<== предыдущая лекция | следующая лекция ==>