[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Свободные мысли о свободном софте
[an error occurred while processing this directive]
Logo CitForum CITForum на CD Форумы Газета Море(!) аналитической информации!
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive]
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

26.05.2018

Google
WWW CITForum.ru
[an error occurred while processing this directive]

Новости мира IT:

Архив новостей

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]
Пятнадцатая техническая конференция «Корпоративные базы данных-2010»
Москва, 22–23 апреля
С Новым годом!

Генеральный спонсор
Техническая конференция
Корпоративные базы данных – 2008
Москва, 24–25 апреля
При поддержке РФФИ

Спонсор
[an error occurred while processing this directive] [an error occurred while processing this directive]
На правах рекламы
2010 г.

Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения


к.т.н. И.М. Слюсаренко, к.т.н. М.Ю Слюсаренко, «InfoSoftCom»

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

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

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

Содержание

1. Понятие системы
2. Материальные и знаковые системы. Программные системы как разновидность знаковых
3. Эмергентность свойств систем
4. Понятие объекта, объектно-ориентированной модели
5. Декомпозиция
6. Синтез и анализ в изучении сложных систем
7. Обобщенное правило декомпозиции
8. Особенности проектирования программных систем
9. Системологическое описание проектирования программных систем
10. Заключение
Список литературы

1. Понятие системы

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

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

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

2. Материальные и знаковые системы. Программные системы как разновидность знаковых

Системы делятся на материальные и знаковые. Последние, в той или иной мере отражающие первые, называются их знаковыми моделями [1]. Наши представления о материальных образованиях являются знаковыми моделями, или знаковыми системами, которые в свою очередь образуют иерархию подсистем. Все основные понятия материальных систем применимы и к знаковым системам.

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

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

3. Эмергентность свойств систем

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

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

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

4. Понятие объекта, объектно-ориентированной модели

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

По определению Г.Буча, объект – это нечто, чем можно оперировать. Объект имеет состояние, поведение и идентичность [4, стр.473]. Объект в методологии объектно-ориентированного проектирования с точки зрения системологии является знаковым объектом. Г.Буч в своей книге [4, стр.92] приводит определение Смита и Токи: «Объект представляет собой конкретный опознаваемый предмет, единицу или сущность (реальную или абстрактную), имеющую четко определенное функциональное назначение в данной предметной области». Состояние объекта характеризуется перечнем (обычно статическим) всех свойств данного объекта и текущими (обычно динамическими) значениями каждого из этих свойств [4, стр.94]. К числу свойств объекта относятся присущие ему или приобретаемые им характеристики, делающие объект самим собой [4, стр.94]. Поведение – это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений [4, стр.96].

Объектная модель – это совокупность основополагающих принципов, лежащих в основе объектно-ориентированного проектирования, и/или парадигма программирования, основанная на принципах абстрагирования, инкапсуляции, модульности, иерархичности, типизации, параллелизма и устойчивости [4, стр.473]. Абстракция – это существенные характеристики объекта, которые отличают его от всех других объектов и четко определяют его концептуальные границы для наблюдателя. Абстрагирование – процесс выявления абстракций [4, стр.468]. Инкапсуляция – это процесс объединения и защиты элементов абстракции, которые образуют ее структуру и поведение. Служит для отделения внешних обязательств объекта от его реализации [4, стр.471].

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

Иерархия – это подчинение или упорядочение абстракций [4, стр.471]. Типизация – механизмы, препятствующие замене объектов одного типа на другой или, в крайнем случае, жестко ограничивающие такую замену [4, стр.477]. Параллелизм – это свойство, отличающее активные объекты от неактивных. Параллельный объект – активный объект, способный работать в многопоточной среде [4, стр.474].

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

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

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

Под полнотой подразумевается наличие в интерфейсной части класса всех характеристик абстракции. Примитивными являются только такие операции, которые требуют доступа к внутренней реализации абстракции [4, стр 139]. Таким образом, можно сделать следующие выводы:

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

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

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

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

5. Декомпозиция

Выделение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования [4 стр. 148], которая осуществляется в процессе декомпозиции ключевых абстракций программной системы.

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

Г. Буч в своей книге задает непростой вопрос [4, стр. 40]: существует ли наилучший метод проектирования? На этот вопрос однозначного ответа нет. По сути дела этот вопрос сводится к другому вопросу: существует ли лучший способ декомпозиции сложной системы? Если он и существует, то пока никому не известен. Также этот вопрос можно поставить и по-другому: как наилучшим способом разделить сложную систему на подсистемы? Правильное разделение системы на составные части, представление предметной области в виде набора объектов, или разбиение программы на модули является почти такой же сложной задачей, как выбор правильного набора абстракций.

Г. Буч в своей книге приводит [4, стр. 69] правило Клеменса и Вейса, которым активно пользуются разработчики программного обеспечения при выделении модулей программ: «Особенности системы, подверженные изменениям, следует скрывать в отдельных модулях; в качестве межмодульных можно использовать только те элементы, вероятность изменения которых мала». Также необходимо отметить, что поскольку модули служат элементарными и неделимыми блоками программы, которые могут использоваться повторно, это должно учитываться при распределении классов и объектов по модулям.

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

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

Таким образом, в общем случае сложная система представляется как многоуровневая конструкция из взаимодействующих элементов, объединяемых в подсистемы различных уровней. Разделение системы на элементы в общем случае может быть выполнено неоднозначным образом и является в высшей степени условным.» [5, стр.19]

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

6. Синтез и анализ в изучении сложных систем

Разделение или декомпозиции применяется в случаях, когда рассматривается существующая система или проектируется новая. При этом применяются два фундаментальных понятия системологии: анализ (как было сформулировано – рассмотрение) и синтез (проектирование) систем. Задачи анализа определяются как изучение свойств и поведения системы в зависимости от ее структуры и значений параметров, исходя из заданных свойств системы; задачи синтеза сводятся к выбору структуры и значений параметров, исходя из заданных свойств системы [5, стр.37].

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

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

7. Обобщенное правило декомпозиции

Зададим в общем виде функционал эффективности системы в виде следующего выражения: А = F(a1,…,an), где А – показатель, отражающий качество реализации основного назначения системы (например, некоего системного качества или эмергентного свойства), a1,…,an – параметры, от которых зависит данное системное качество (они также могут быть функционально зависимыми от других параметров).

В качестве пояснения назначения функционала рассмотрим задачу увеличения высоты полета самолета. Пусть А – высота полета самолета. Первый вопрос, на который должен ответить человек, решающий данную задачу – от чего зависит высота полета? Для простоты рассмотрим два составляющих элемента самолета: двигатель, крылья, и, кроме того, саму систему – самолет. Выделим свойства, оказывающие влияние на заданное системное свойство, например, в двигателе – мощность (пусть это а), в крыльях – площадь (с), а в самолете его вес (b).

Значит, для увеличения системного качества А нужно рассмотреть возможности синтеза такой структуры рассмотренных элементов при которой значения показателей а, b, с приведут к требуемому результату. Это очевидный пример синтеза через анализ.

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

Таким образом, в общем виде правило декомпозиции заключается в выполнении следующих основных этапов:

  1. Определение системных(ого) свойств(а), значимых (ого) для решения поставленной задачи. В примере – высота полета самолета.
  2. Поиск составных частей системы и их свойств, оказывающих решающие влияние на выделенные системные свойства. В примере – двигатель (мощность), крылья (площадь), самолет (вес).

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

8. Особенности проектирования программных систем

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

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

Наиболее адекватное определение архитектуры, на наш взгляд приведено в [4, стр. 470]: архитектура – это логическая и физическая структура системы, сформированная всеми стратегическими и тактическими проектными решениями. Хорошей архитектуре присуще следующие основные черты:

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

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

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

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

Г.Буч приводит мнение Ингалса [4, стр. 138], отражающие суть модульности: «для построения системы должен использоваться минимальный набор неизменяемых компонент; сами компоненты должны быть по возможности стандартизованы и рассматриваться в рамках единой модели». Применительно к объектно-ориентированному проектированию такими компонентами являются классы и объекты, отражающие ключевые абстракции системы, а единство обеспечивается соответствующими механизмами реализации.

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

9. Системологическое описание проектирования программных систем

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

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

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

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

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

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

10. Заключение

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

Список литературы

  1. Флейшман Б. С. Основы системологии, М.: Радио и Связь. 1982.
  2. Слюсаренко И.М., Слюсаренко М.Ю. Системный подход в автоматизации процессов компаний.
  3. Слюсаренко И.М., Слюсаренко М.Ю. Основы системологии и автоматизация бизнес-процессов компаний.
  4. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С ++, 2-е изд./Пер. с англ .- М.: «Издательство Бином», СПб.: «Невский диалект», 1999 г.
  5. Бусленко Н. П. Моделирование сложных систем. М.: Наука. 1978г.
[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive]

Планирование сроков проекта и вопросы осуществления лидерством проекта рассматриваются на сайте по управлению проектами.

[an error occurred while processing this directive]
[an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Размещение рекламы — тел. +7 495 6608306, ICQ 232284597

[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive]

Редакция рекомендует:

Последние комментарии:

Что мы знаем об iPhone 4G? (7)
16 июля, 20:25

Подписка на новости CITForum.ru

Новые публикации:

7 июля

  • Управление параллелизмом с низкими накладными расходами для разделенных баз данных в основной памяти

  • Рекурсивные запросы в Oracle

  • Жесткий диск WD10EARS с сектором 4 КБ. Подготовка к эксплуатации в Linux.

    Обзоры журнала Computer:

    Газета:

  • Московские пробки - исследование IBM

  • От Osborne до iPad: эволюция портативных компьютеров

    19 мая

  • Прозрачный механизм удаленного обслуживания системных вызовов

  • Система моделирования Grid: реализация и возможности применения

    Газета:

    Майкл Стоунбрейкер:

  • Ошибки в системах баз данных, согласованность "в конечном счете" и теорема CAP

  • Дискуссия по поводу "NoSQL" не имеет никакого отношения к SQL

    29 апреля

  • Материалы конференции "Корпоративные Базы Данных-2010"

  • Разные облики технологии баз данных (отчет о конференции)

    14 апреля

  • MapReduce: внутри, снаружи или сбоку от параллельных СУБД?

  • Научные вызовы технологиям СУБД

    Обзоры журнала Computer:

    31 марта

  • Рационализация согласованности в "облаках": не платите за то, что вам не требуется

  • Взаимные блокировки в Oracle

  • Архитектура среды тестирования на основе моделей, построенная на базе компонентных технологий

  • Объектное представление XML-документов

    Газета:

  • Microsoft для российских разработчиков: практика с элементами фундаментальности

    10 марта

  • HadoopDB: архитектурный гибрид технологий MapReduce и СУБД для аналитических рабочих нагрузок

  • Классификация OLAP-систем вида xOLAP

  • BGP. Три внешних канала. Балансировка исходящего и входящего трафиков

    Газета:

  • Что мы знаем об iPhone 4G?

    17 февраля

  • MapReduce и параллельные СУБД: друзья или враги?

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

  • Системологический подход к декомпозиции в объектно-ориентированном анализе и проектировании программного обеспечения

    Газета:

  • Эволюция Wine

    3 февраля

  • Дом на песке

  • Реальное переосмысление "формальных методов"

  • Интервью с Найджелом Пендзом

    Газета:

  • iPad. Первый взгляд на долгожданный планшет от Apple

  • Я не верю в iPad [an error occurred while processing this directive]

    20 января

  • SQL/MapReduce: практический подход к поддержке самоописываемых, полиморфных и параллелизуемых функций, определяемых пользователями

  • Данные на лету: как технология потокового SQL помогает преодолеть кризис

    Обзоры журнала Computer:

    2 декабря

  • Сергей Кузнецов. Год эпохи перемен в технологии баз данных

    18 ноября

  • Генерация тестовых программ для подсистемы управления памятью микропроцессора

  • Сравнительный анализ современных технологий разработки тестов для моделей аппаратного обеспечения

    Все публикации >>>


    [an error occurred while processing this directive]
  • [an error occurred while processing this directive] [an error occurred while processing this directive]
    Купить сотовые телефоны в М.Видео
    Отличные цены на сотовые телефоны. Бесплатная доставка. Заказ в интернет-магазине и по телефону (495) 644-28-51
    www.mvideo.ru [an error occurred while processing this directive]

    Регистрация доменов в зонах .ru, .com, .net. Компания Rusonyx.

    IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    [an error occurred while processing this directive]
    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 6608306, ICQ 232284597 Пресс-релизы — pr@citforum.ru
    Послать комментарий
    Информация для авторов

    Редакция раздаёт котят!

    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2009 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...
    [an error occurred while processing this directive]


    [an error occurred while processing this directive] [an error occurred while processing this directive] реклама:
    Производство и продажа серверов | забронировать гостиницу Санкт Петербурга | платный хостинг | IBM Rational. Аналитика и инструменты
    [an error occurred while processing this directive] [an error occurred while processing this directive]