История развития программирования в России»

Содержание:

ВВЕДЕНИЕ

Прогресс компьютерных технологий определил процесс появления новых разнообразных знаковых систем для записи алгоритмов – языков программирования. Смысл появления такого языка – упрощение программного кода. С каждым днём наш мир становиться более мобильным и информационным. Всё больше и больше компьютеры вступают в нашу повседневную жизнь и чтобы облегчить наше общение с ними создаётся новое ПО с помощью различных языков программирования. Целью данной курсовой работы является изучение истории возникновения программирования и основных принципов и подходов при создании языка программирования.

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

Предмет исследования – история развития программирования в России.

Целью исследования в курсовой работе является углубленное изучение истории развития программирования в России.

Для достижения поставленной цели сформулированы следующие задачи:

1. изучить теоретические основы развития программирования;
2. рассмотреть практику программирования.

Методологической основой исследования являются учебная и методическая литература по программированию, статьи в периодической печати и Интернет-ресурсы.

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗВИТИЯ ПРОГРАММИРОВАНИЯ

1.1. Исторические этапы развития языков программирования

С глубокой древности известны попытки создать устройства, ускоряющие и облегчающие процесс вычислений. Еще древние греки и римляне применяли приспособление, подобное счетам, -- абак. Такие устройства были известны и в странах Древнего Востока. В XV в. немецкие ученые В. Шиккард (1623), Г.Лейбниц (1673) и французский ученый Б. Паскаль (1642) создали механические вычислительные устройства -- предшественники всем известного арифмометра. Вычислительные машины совершенствовались в течении нескольких веков. Но при этом не применялось понятие «программа и программирование».

В начале XIX в. (1830) английский ученый, профессор математики Кэмбриджского университета Чарльз Бэббидж, анализируя результаты обработки переписи населения во Франции, теоретически исследовал процесс выполнения вычислений и обосновал основы архитектуры вычислительной машины. Работая над проектом аналитической машины - «Машины для исчисления разностей», Ч. Бэббидж предсказал многие идеи и принципы организации и работы современных ЭВМ, в частности принцип программного управления и запоминаемой программы. Общая увлеченность наукой дала ученому и Аде Лавлейс (1815--1852) долгие годы плодотворного сотрудничества. В 1843 г. она перевела статью Менабреа по лекциям Ч. Бэббиджа, где в виде подробных комментариев (по объему они превосходили основной текст) сформулировала главные принципы программирования аналитической машины. Она разработала первую программу (1843) для машины Бэббиджа, убедила его в необходимости использования в изобретении двоичной системы счисления вместо десятичной, разработала принципы программирования, предусматривающие повторение одной и той же последовательности команд при определенных условиях. Именно она предложила термины «рабочая ячейка» и «цикл».

А. Лавлейс составила первые программы для решения системы двух уравнений и вычисления чисел Бернулли по довольно сложному алгоритму и предположила, что со временем аналитическая машина будет сочинять музыкальные произведения, рисовать картины и использоваться в практической и научной деятельности. Время подтвердило ее правоту и точность прогнозов. Своими работами А. Лавлейс заложила теоретические основы программирования и по праву считается первым в мире программистом и основоположником научного программирования.

В 1854 г. английский математик Джордж Буль опубликовал книгу «Законы мышления», в которой развил алгебру высказываний --Булеву алгебру. На ее основе в начале 80-х гг. XIX в. построена теория релейно-контактных схем и конструирования сложных дискретных автоматов. Алгебра логики оказала многогранное влияние на развитие вычислительной техники, являясь инструментом разработки и анализа сложных схем, инструментом оптимизации большого числа логических элементов, из многих тысяч которых состоит современная ЭВМ.

Идеи Ч. Бэббиджа реализовал американский ученый Г. Холлерит, который с помощью построенной счетно-аналитической машины и перфокарт за три года обработал результаты переписи населения в США по состоянию на 1890г. В машине впервые было использовано электричество. В 1896 г. Холлеритом была основана фирма по выпуску вычислительных перфорационных машин и перфокарт.

В 1936 г. английский математик А. Тьюринг ввел понятие машины Тьюринга, как формального уточнения интуитивного понятия алгоритма. Ученый показал, что любой алгоритм в некотором смысле может быть реализован на машине Тьюринга, а следовательно, доказывал возможность построения универсальной ЭВМ. И та, и другая машины аналогично могут быть снабжены исходными данными решаемой задачи и программой ее решения. Машину Тьюринга можно считать как бы идеализированной моделью универсальной ЭВМ. В 40-х гг. XX в. механическая элементная база вычислительных машин стала заменяться электрическими и электронными устройствами. Первые электромеханические машины были созданы в Германии К. Цузе (Ц-3, 1941г.) и в США под руководством профессора Гарвардского университета Г. Айкена (МАРК-1, 1944 г.). Первая электронная машина создана в США группой инженеров под руководством доктора Пенсильванского университета Дж. Мочли и аспиранта Дж. Экксрта (ЭНИАК -- электронный числовой интегратор и калькулятор, 1946 г.). В 1949 г. в Англии была построена EDSAC -- первая машина, обладающая автоматическим программным управлением, внутренним запоминающим устройством и другими необходимыми компонентами современных ЭВМ.

Логические схемы вычислительных машин были разработаны в конце  1940-х гг. Дж. фон Нейманом, Г. Гольдстайном и А. В. Берксом. Особый вклад в эту работу внес американский математик Джон фон Нейман, принимавший участие в создании ЭНИАК. Он предложил идею хранения команд управления и данных в машинной памяти и сформулировал основные принципы построения современных ЭВМ. ЭВМ с хранимой программой оказались более быстродействующими и гибкими, чем ранее созданные.

В 1951 г. в США было налажено первое серийное производство электронных машин УНИВАК (универсальная автоматическая вычислительная машина). В это же время фирма IBM начала серийный выпуск машины IBM/701.

В СССР первыми авторами ЭВМ, изобретенной в декабре 1948 г., являются И. С. Брук и Б. И. Рамеев. А первая советская ЭВМ с сохраняющейся программой создана в 1951 г. под руководством С. А Лебедева (МЭСМ -- малая электронная счетная машина). В 1953 г. в Советском Союзе начался серийный выпуск машин, первыми их которых были БЭСМ-1, «Стрела».

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

До конца 1950-х гг. ЭВМ основным элементом конструкции были электронные лампы (1-е поколение). В этот период развитие идеологии и техники программирования шло за счет достижений американских ученых Дж. фон Неймана, сформулировавшего основные принципы построения ЭВМ, и Дж. Бэкуса, под руководством которого в 1954 г. был создан Fortran (Formula Translation) -- первый язык программирования высокого уровня, используемый до настоящего времени в разных модификациях. Так, в 1965 г. в Дартмутском колледже Д. Кэмэни и Т. Куртцем была разработана упрощенная версия Фортрана -- Basic. В 1966 г. комиссия при Американской ассоциации стандартов (ASA) разработала два стандарта языка: Фортран и Базисный Фортран. Используются также дальнейшие модификации языка (например 1970, 1990 гг.).

Достижения в области электроники и микроэлектроники позволили заменить элементную базу ЭВМ на более совершенную. В конце 1950-х гг. громоздкие электронные лампы заменяют полупроводниками (миниатюрными транзисторами). Появляются ЭВМ II поколения; затем примерно через 10 лет -- ЭВМ III поколения на интегральных схемах; еще через 10 лет -- ЭВМ IV поколения на больших интегральных схемах (БИС). В Японии в 1990-х гг. реализованы проекты ЭВМ V поколения, в которых использованы достижения в области искусственного интеллекта и биоэлектроники. Если объем оперативного запоминающего устройства (ОЗУ) одной из лучших отечественных машин 1960-х гг. М-20, созданной под руководством С.А.Лебедева в 1958 г., имел 4096 слов (8 Кбайт) и быстродействие 20 тыс. операций в секунду, то современные персональные компьютеры характеризуются ОЗУ в десятки Мбайт и быстродействием в сотни миллионов операций в секунду, что позволяет решать сложнейшие задачи.

В 1953 г. А.А.Ляпуновым был предложен операторный метод программирования, который заключался в автоматизации программирования, а алгоритм решения задачи представлялся в виде совокупности операторов, образующих логическую схему задачи. Схемы позволяли расчленить громоздкий процесс составления программы, части которой составлялись по формальным правилам, а затем объединялись в целое. Для проверки идей операторного метода в СССР в 1954 г. была разработана первая программирующая программа ПП-1, а в 1955 г. более совершенная -- ПП-2. В 1956 г. разработана ПП БЭСМ, в 1957 г. - ППСВ, в 1958 г. -- для машины «Стрела».

В США в 1954 г. стал применяться алгебраический подход, совпадающий, по существу, с операторным методом. В 1956 г. корпорацией IBM разработана универсальная ПП Фортран для автоматического программирования на ЭВМ IBM/704. В этот период по мере накопления опыта и теоретического осмысления совершенствовались языки программирования. В 1958--1960 гг. в Европе был создан ALGOL, который породил целую серию алголоподобных языков: Algol W, (1967), Algol 68, Pascal (Н. Вирт, 1970 г.), С (Д. Ритчи и Б. Керниган, 1972 г.), Ada (под руководством Ж. Ишбиа, 1979 г.), C++ (1983). В 1961-1962 гг. Дж. Маккарти в Массачусетском технологическом институте был создан язык функционального программирования Lisp, открывший в программировании одно из альтернативных направлений, предложенных Дж. фон Нейманом. На начало 1970-х гг. существовало более 700 языков высокого уровня и около 300 трансляторов для автоматизации программирования.

1.2. Русские программисты, внесшие вклад в историю программирования

Россия традиционно ассоциируется с огромной территорией и бесконечными природными ресурсами. Нефть, газ, уголь и древесина по-прежнему остаются наиболее важными составляющими валового национального продукта России, на этом фоне индустрия программирования почти незаметна. Однако, помимо лидерства на сырьевом рынке, Россия занимает первое место в мире по количеству технических специалистов. Согласно отчету World Bank/UNESCO, более миллиона человек в стране работает в области научных исследований. У России есть все предпосылки для того, чтобы стать заметной силой на международном рынке программирования.

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

В те времена количество программистов (да и самих компьютеров) было очень небольшим, так как область применения программирования была достаточно ограниченной. Так, за все 20 лет производства БЭСМ-6, одного из самых успешных компьютеров тех времен (было выпущено всего около 300 штук). Тем не менее, к концу 60-х советская школа программирования находилась на мировом уровне и в промышленной разработке программ, и в научных исследованиях.

Не зря русские программисты очень ценятся за рубежом, множество русских специалистов в области IT-технологий работают и принимали участие в разработке и продвижении крупных сервисов, программ и компаний. Таких как GOOGLE,YAHOO и других.

Проанализируем вклад в развитие программирования самых известных и знаменитых программистов СССР и России.

Давид Ян. Российская компания ABBYY (до 1997 год а – BIT Software) была основана в 1989 г. в Москве студентом четвертого курса Московского физико-технического института (МФТИ) Давидом Яном.

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

В группу компаний ABBYY входит десять международных офисов в России, США, Германии, Великобритании, Японии, Тайване, на Украине и Кипре, высокотехнологичное российское агентство по переводу ABBYY Language Services (Perevedem.ru) и издательство ABBYY Press. Головной офис ABBYY, находящийся в Москве, отвечает за разработку продуктов и координацию деятельности офисов компании в других странах.

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

Бакунов Григорий Николаевич (род. 19 апреля 1972 года). С 2001 г. руководил отделом разработки в SWSoft. В настоящее время является заместителем руководителя департамента разработки компании Яндекс. Ранее работал по рабочим контрактам в Бельгии, Израиле и США.

Внес вклад в разработку ряда программ с открытым исходным кодом, в том числе ASPLinux.

Евгений Валентинович Касперский (4 октября 1965 г., Новороссийск) – российский программист, специалист по информационной безопасности, один из основателей, ведущий разработчик и крупнейший акционер ЗАО «Лаборатория Касперского» – международной компании, занимающейся разработкой решений для обеспечения IT-безопасности, имеющей более 30 региональных офисов и ведущей продажи в 200 странах. Лауреат Государственной Премии в области науки и технологий за 2008 год. В прессе характеризуется как «гроза компьютерной преступности»

Сергей Михайлович Брин родился 21 августа 1973 г., в Москве, СССР. Разработчик и сооснователь поисковой системы Google. легенда компьютерного бизнеса, сооснователь и президент по технологии компании Google Inc., миллиардер, ныне один из самых богатых людей Америки. Брин – русский, впервые названный газетой «Financial Times» «человеком года» не как актер, политик или олигарх, а как математик, прославившийся на весь мир творением собственного ума – поисковой системой Google.

ГЛАВА 2 ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ ПРОГРАММИРОВАНИЯ UML

Особенности языка программирования UML

Как и все формальные искусственные языки UML имеет синтаксис, семантику и прагматику, но они названы другими терминами и описываются иначе, чем это принято в текстовом языке программирования, из-за того, что UML является графическим языком, а не текстовым, а так же языком моделирования, а не программирования.

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

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

Рис.1. История развития языка UML [3]

Все крупные поставщики инструментов предпочитают поддерживать версию 2.0 и оставлять без поддержки версию 1.5.

Язык UML предназначается для создания моделей систем. Сами авторы UML (Г. Буч, Д. Рамбо и А. Якобсон) определяют его как графический язык построения диаграмм, который предназначается для выполнения процессов определения требований, построения структуры системы, проектирования и документирования всех этапов, разработки программных средств [2].

1. Определение требований

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

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

2. Построение структуры системы

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

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

3. Проектирование

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

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

4. Документирование

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

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

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

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

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

Абстракция является фундаментальным человеческим потенциалом, который позволяет нам иметь дело со сложными системами.

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

Люди строят модели сложных систем, потому что возникают сложности понимания и анализа их во всей полноте. Есть ограничения на способность человека понять сложность. Эта концепция может рассматриваться на примере архитектуры. Глядя на строки исходного кода даже анализ формы в Visual Basic дает мало информации для того, чтобы обеспечить программисту понимание всего целиком.

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

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

Часто используют треугольник, как показано на рисунке 2, чтобы объяснить компоненты, необходимые для успешной реализации проекта [6]. Вы должны обозначить все три грани, нотация, процесс, и инструмент. Вы можете знать нотацию, но если вы не знаете, как ее использовать (Процесс), вам, вероятно, моделирование не удастся. Вы можете иметь отличный процесс, но если вы не можете взаимодействовать с процессом (нотация), вам, вероятно, моделирование так же не удастся. И, наконец, если вы не можете документировать свою работу (инструмент), вам также моделирование не удастся.

Рис.2. Треугольник взаимодействия нотации процесса и инструмента [6]

Роль нотации

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

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

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

• Она предлагает вид достаточный для людей, чтобы рассуждать и инструменты для манипулировать. [1]

Unified Modeling Language (UML) обеспечивает очень надежную нотацию, которая растет от анализа к дизайну. Некоторые элементы нотации (например, классы, ассоциации, агрегации, наследования) вводятся в процессе анализа. Другие элементы записи (например, показатели реализации защитной оболочки и свойства) введены во время проектирования.

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

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

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

Поэтому, в языке UML применяется четыре основных типа графических элементов:

1. Значки или пиктограммы. Значки являются графическими фигурами фиксированных размеров и формы. Они не могут увеличивать свои размеры, для размещении внутри себя дополнительных символов. Значки могут располагаться либо внутри других графических элементов, либо вне их. Примером значков является окончания связей элементов диаграмм.
2. Графические символы на плоскости. Эти символы принято изображать с использованием различных геометрических фигур, они могут иметь разную высоту и ширину для размещения внутри них других языковых конструкций UML. Чаще всего внутри этих символов помещают текстовые строки, которые уточняющие семантику или фиксирующие некоторые свойства элементов языка UML. Данные, содержащиеся внутри фигур, имеют важное значение для конкретных моделей проектируемых систем, так как регламентируют реализацию соответствующих элементов программного кода.
3. Пути, представляющие собой последовательность отрезков линий, которые соединяют отдельные графические символы. При этом концевые точки на отрезках линий должны качаться с геометрических фигур, служащих для обозначения вершин диаграмм. С концептуальной точки зрения пути в языке UML имеют особое значение, так как являются простыми геометрическими структурами. Другими словами, пути не могут обрываться на диаграмме линией, не соприкасающейся ни с одним графическим символом. Как было сказано выше, пути могут иметь в качестве окончания специальные графические фигуры - значки, которые изображаются на одном из концов линий, являющихся сегментами этого пути.
4. Текстовые строки. Они используются для представления различного рода информации в грамматическом виде. Каждое применение строк текста должно соответствовать синтаксису в нотациям языка UML, с помощью которого могут быть реализованы грамматические разборы этих строк. Разбор важен для получения полных данных о модели. К примеру, строки текста в различных областях классов могут соответствовать атрибутам этого класса или его операциям. На использование строк накладывается важное условие - семантика всех допустимых символов должна быть заранее определена в языке UML или служить предметом его расширения в конкретной модели.

1.2. Основные особенности построения диаграмм языка UML

По мнению Г. Буча, в UML версии 1 всего определяется 9 различных видов диаграмм. Ими являются [8]:

1. Диаграммы использования (Use Case diagrams);
2. Диаграммы классов (Class diagrams);
3. Диаграммы объектов (Object diagrams);
4. Диаграммы состояний (State chart diagrams);
5. Диаграммы деятельности (Activity diagrams);
6. Диаграммы последовательности (Sequence diagrams);
7. Диаграммы кооперации (Collaboration diagrams);
8. Диаграммы компонентов (Component diagrams);
9. Диаграммы размещения (Deployment diagrams).

Данная классификация проиллюстрирована на рисунке 3.

Рис.3. Классификация видов диаграмм в языке UML I[8]

Язык UML I значительно отличается списком диаграмм - их число увеличивается до 13. Помимо этого две диаграммы переименованы: диаграмму кооперации переименовали в диаграмму коммуникации, а диаграмму состояний в диаграмму автомата.

Классификация диаграмм в языке UML 2 приведена на рисунке 4.

Рис.4. Классификация видов диаграмм в языке UML 2

Диаграммы вариантов использования (use case diagrams) являются самым общим представлением функциональных назначений системы.

Диаграмму вариантов использования создают для ответа на основной вопрос моделирования: для какой функции создается система.

На диаграммах вариантов использования имеется два вида основных сущностей: варианты использования (1) и действующие лица (2). Между этими сущностями формируют следующие отношения:

- ассоциацию между лицами и вариантами использования (3);

- обобщение между действующими лицами (4);

- обобщение между вариантами использования (5);

- зависимость между вариантами использования (6).

На диаграммах вариантов использования могут добавляться примечания (7).

Все вышеперечисленные элементы, присутствующие на диаграммах вариантов использования, приведены на рисунке 5.

Рис.5. Диаграмма вариантов использования

Диаграммы классов (class diagram) являются основным способом формирования структур систем. Так как UML является объектно-ориентированным языком, то класс является основным строительным блоком.

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

- ассоциации между классами (2);

- обобщения между классами (3);

- зависимость (разных типов) между классами (4), между классами и интерфейсами.

Все элементы диаграммы, рассмотренные выше представлены на рисунке 6.

Рис.6. Диаграмма классов

Диаграммs деятельности (activity diagramы) являются еще одним способом при описании поведения. Они чем-то напоминают старые добрые блок-схемы алгоритмов.

Из-за новых обозначений, которые согласованы с объектно-ориентированными подходами, диаграммы деятельности языка UML представляют собой мощное средство в описании поведения систем. На диаграмме деятельности используется одна основная сущность — действие (1), и один тип отношений — переход (2). Помимо этого имеются конструкции типа развилок, слияний, соединений, ветвлений (3), похожих на сущности, но не являющихся ими. Эти конструкции являются графическим способом изображений некоторых частных случаев гипердуги в гиперграфах. Основные элементы диаграммы деятельности изображены на рисунке 7.

Рис.7. Диаграммы деятельности

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

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

Рис.8. Диаграмма коммуникации

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

ГЛАВА 3 ПРАКТИКА ПРОГРАММИРОВАНИЯ

3.1 Построение диаграммы прецедентов по видам экономической деятельности

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

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

Рассмотрим описание процесса.

Дежурный врач организует прием пациента, что подразумевает оформление истории болезни, проведение анализов, первичный осмотр, оповещает родственников пострадавшего. В случае тяжелого состояния пациента он направляется в реанимацию. Если состояние пациента безнадежно, от родственников испрашивается согласие на трансплантацию органов. Разрабатываемая система должна автоматизировать выдачу направлений на анализы, предоставляя пакет документов для оформления согласия родственников. Истории болезни в организации ведутся в бумажной форме (результаты анализов в историю болезни вклеиваются).

В таблице 1 представлено описание действующих лиц для предметной области «Поступление пациента в больницу в приемное отделение».

Таблица1

Описание функций действующих лиц предметной области

Действующее лицо	Характеристика
1	2
Дежурный врач	Специалист, организующий прием пациента, что подразумевает оформление истории болезни, проведение анализов, первичный осмотр, оповещает родственников пострадавшего. В случае тяжелого состояния пациента он направляется в реанимацию. Если состояние пациента безнадежно, от родственников испрашивается согласие на трансплантацию органов.
Лечащий врач	Специалист, который проводит принятие пациента в свое отделение, в зависимости от направления дежурного врача, проводит лечение пациента и его выписку
Лаборатория	Организация, выполняющая взятие анализов у пациентов
Медицинская сестра	Специалист, который оформляет пациента в отделение, выполняет необходимые процедуры.

Рассмотрим функции приемных отделений в ОКБ г. Калуга и ОКБ г. Тверь.

Функции действующих лиц в областных клинических больницах ОКБ г. Калуга и ОКБ г. Тверь представлены в таблице 2.

Таблица 2

Описание Действующие лица и их функции в областных клинических больницах ОКБ г. Калуга и ОКБ г . Тверь

Действующее лицо	Функции
Дежурный врач	Оформляет прием пациента, проводит необходимые анализы и диагностические процедуры, осмотр, оформляет историю болезни, оповещает родственников, при необходимости оформляет согласие на трансплантацию органов, так же при необходимости направляет пациента в отделение интенсивной терапии	Ведет прием пациентов, назначает анализы, проводит осмотр и другие диагностические процедуры, проводит оповещение родственников и оформление необходимых согласий, выписывает направления в различные отделения больницы на лечение
Лечащий врач	Получает историю болезни, принимает пациента в свое отделение, проводит дальнейшее лечение и выписку пациента	Заполнение истории болезни, проведение дальнейшего лечения и выписка пациента
Медицинская сестра	Оформляет необходимую документацию в истории болезни и располагает пациента в отделении	Размещение пациента, выполнение предписаний врача, оформление документации
Лаборатория	Берет анализы и выдает результаты по направлению врача	Забор анализов и выдача результатов

Анализ функций в приемных отделениях больниц ОКБ г. Калуга и ОКБ г . Тверь показал, что в процессе работы, выполняются одни и те же функции, перечисленные в таблице 2.

Для построения диаграммы прецедентов была использована программа Microsoft Visio 2013. Диаграмма прецедентов для предметной области « Поступление пациента в больницу в приемное отделение» представлена на рисунке 9.

Рис.9. Диаграмма прецедентов для предметной области «Поступление пациента в больницу в приемное отделение» [2]

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

Исходя из этого для предметной области «Поступление пациента в больницу в приемное отделение» присвоены эти функции, которые представлены на рисунке 9.

2.2. Построение диаграммы классов по видам экономической деятельности

Задачами являются: описания классов; изучение элементов диаграммы классов; представление их в виде диаграммы классов по предметной области «Поступление пациента в больницу в приемное отделение»; построение информационного процесса управления в виде диаграммы классов с использованием программы Microsoft Visio 2013.

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

Сначала рассмотрим соответствующие элементы и пакеты документов, которые представлены в таблице 3.

Таблица 3

Имя класса	Атрибуты класса	Операции класса
Дежурный врач	ФИО: Иванников Игорь Петрович., Должность: дежурный врач-терапевт 1 категории, Адрес: Калужская область, г. Калуга, ул. Кутузова,3, 14.	Оформление приема пациента; Проведение необходимых анализов; Проведение осмотра; Оформление истории болезни; Оповещение родственников; При необходимости, оформление согласия на трансплантацию органов; При необходимости направление пациента в отделение интенсивной терапии.
Медицинский персонал больницы	Адрес: Калужская область, г. Калуга, ул. Вишневского,12	Прием пациента в отделение; Размещение пациента; Лечение пациента; Выписка пациента.
Лечащий врач	ФИО: Жилина Анна Леонидовна., Должность: врач-терапевт высшей категории, Адрес: Калужская область, г. Калуга, ул. Гагарина,15,4	Получение истории болезни;
Медсестра	ФИО: Карелина Ирина Сергеевна., Должность: старшая медицинская сестра, Адрес: Калужская область, г. Калуга, ул. Анненки,35	Получение истории болезни;
Лаборатория	Адрес: Калужская область, г. Калуга, ул. Вишневского,12	Взятие анализов

Схема взаимодействия данных элементов подробно рассмотрена в диаграмме классов на рисунке 10.

Рисунок 10. Диаграмма классов для предметной области «Поступление пациента в больницу в приемное отделение»[2]

В итоге была построена диаграмма классов для предметной области «Поступление пациента в больницу в приемное отделение», функции для которой описаны на основе анализа в таблице 3.

2.3 Построение диаграммы видов деятельности

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

Рассмотрим алгоритм выполнения процесса по предметной области «Поступление пациента в больницу в приемное отделение»; выполним построение этого алгоритма в виде диаграммы деятельности с использованием программы Microsoft Visio 2013.

Рис. 11. Диаграмма видов деятельности процесса " Поступление пациента в больницу в приемное отделение ".

На диаграмме изображен алгоритм деятельности приемного отделения. Рассмотрим его основные этапы в таблице 4.

Таблица 4

Основные этапы диаграммы деятельности

Номер этапа	Дежурный врач	Лаборатория	Мед. персонал больницы
1.	Оформление приема пациента
2.	Проведение осмотра пациента
3.	Определение достаточности данных для диагноза
4.	Если данных достаточно, то определение необходимости реанимации
5.	Если данных не достаточно, выписка направления на анализы
6.		Взятие анализов
7.	Если необходима реанимация, то выписка направления в отделение интенсивной терапии
8.	Если реанимация не нужна, то оформление согласия на трансплантацию, при необходимости
9.	Передача истории болезни
10			Получение истории болезни

В итоге была построена диаграмма деятельности для предметной области «Поступление пациента в больницу в приемное отделение», функции для которой описаны на основе анализа в таблице 4.

2.4. Построение диаграмм взаимодействия(последовательности) по видам экономической деятельности

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

Рассмотрим последовательность взаимодействия трех объектов предметной области «Поступление пациента в больницу в приемное отделение»; выполним построение последовательности в виде диаграммы деятельности с использованием программы Microsoft Visio 2013.

Рис.12. Диаграмма последовательности процесса "Поступление пациента в больницу в приемное отделение"

Четырьмя объектами на диаграмме последовательности являются:

• Лечащий врач
• Медицинская сестра
• Дежурный врач
• Лаборатория

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

ЗАКЛЮЧЕНИЕ

В результате работы можно сделать ряд выводов. Язык UML является формальным графическим объектно-ориентированным языком, знание которого необходимо при проектировании сложных систем. Модели UML включают описание сущностей и отношения между ними. Элементы модели группированы в диаграммы, чтобы наилучшим образом представлять моделируемую систему с разных точек зрения [2].

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Ф.А. Новиков, Д.Ю. Иванов Моделирование на UML. Теория, практика, видеокурс. — СПб, Профессиональная литература, Изд-во: Наука и Техника, 2010. - 640 с.

2. Г. Буч, Д. Рамбо, А. Якобсон Язык UML. Руководство пользователя. Второе издание. — ДМК, 2006. - 496 с.

3. М. Фаулер UML. Основы. 3-е издание. — Символ-Плюс, 2005, 192 с.

4. Г. Буч, А. Якобсон, Д. Рамбо UML. 2-е издание Классика CS. — Спб., Изд-во: Питер, 2005. - 736 с.

5. Г. Буч, А. Якобсон, Д. Рамбо. Унифицированный процесс разработки программного обеспечения. Изд-во: Питер, 2002. - 496 с.

6. Л. Крэг, Применение UML 2.0 и шаблонов проектирования, 3- е издание. Изд-во: Вильямс, 2007. - 736 с.

7. Д. Рамбо, М. Блаха UML 2.0. Объектно-ориентированное моделирование и разработка. Изд-во: Питер, 2007.- 540 с.

8. Д. Ю. Иванов, Ф. А. Новиков Основы моделирования на UML: Учеб. пособие. – СПб.: Изд-во Политехн. ун-та, 2010. – 249с.