Пять признаков сложной системыИсходя из такого способа изучения, можно вывести пять общих признаков любой сложной системы. Основываясь на работе Саймона и Эндо, Куртуа предлагает следующее наблюдение [7]: 1. "Сложные системы часто являются иерархическими и состоят из взаимозависимых подсистем, которые в свою очередь также могут быть разделены на подсистемы, и т.д., вплоть до самого низкого уровням.";Саймон отмечает: "тот факт, что многие сложные системы имеют почти разложимую иерархическую структуру, является главным фактором, позволяющим нам понять, описать и даже "увидеть" такие системы и их части" [8].: 2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя. Низший уровень для одного наблюдателя может оказаться достаточно высоким для другого.Саймон называет иерархические системы разложимыми, если они могут быть разделены на четко идентифицируемые части, и почти разложимыми, если их составляющие не являются абсолютно независимыми. Это подводит нас к следующему общему свойству всех сложных систем: 3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами" [10]. Это различие внутрикомпонентных и межкомпонентных взаимодействий обуславливает разделение функций между частями системы и дает возможность относительно изолированно изучать каждую часть.Как мы уже говорили, многие сложные системы организованы достаточно экономными средствами. Поэтому Саймон приводит следующий признак сложных систем: 4. "Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных" [11]. Иными словам и, разные сложные системы содержат одинаковые структурные части. Эти части могут использовать общие более мелкие компоненты, такие как клетки, или более крупные структуры, типа сосудистых систем, имеющиеся и у растений, и у животных.Выше мы отмечали, что сложные системы имеют тенденцию к развитию во времени. Саймон считает, что сложные системы будут развиваться из простых гораздо быстрее, если для них существуют устойчивые промежуточные формы [12]. Гэлл [13] выражается более эффектно: 5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы";. В процессе развития системы объекты, первоначально рассматривавшиеся как сложные, становятся элементарными, и из них строятся более сложные
6.1. Введение в программную инженерию (ПО, система и прочее) (Билет 6)
ПО - это компьютерные программы и соответствующая документация. Инженерия ПО – это практическая дисциплина создания и сопровождения программных систем. Модель технологического процесса создания ПО - формализованное упрощенное представление технологического процесса создания ПО. методы инженерии ПО - это структурные решения, предназначенные для разработки ПО и включающие системные модели, формализованные нотацию и правила проектирования, а также способы управления процессом создания ПО. Система — это совокупность взаимодействующих компонентов, работающих совместно для достижения определенных целей. Определяющим признаком системы является то, что свойства и поведение системных компонентов влияют друг на друга сложным образом. Она имеет определенные свойства, которые присущи ей именно как целостной системе. Такие интеграционные свойства не могут быть свойствами отдельной части системы. Они проявляются тогда, когда система рассматривается как единое целое. Цели программных инженеров: Создать качественный продукт. Уложиться в бюджет. Уложиться в сроки. Качественный программный продукт должен: предоставлять требуемую функциональность( Если вы создали продукт, который не нужен конечным пользователям, вы не сможете его продать и не только не получите прибыль, но и не окупите затраты на его создание.) быть удобным в сопровождении( ПО должно допускать развитие в связи с изменением потребностей пользователей. Если Вы начинаете разрабатывать программный продукт, обязательно учитывайте, что мир не стоит на месте. Ваш проект должен быть достаточно гибким, чтобы поддерживать его расширение без ущерба для реализованной ранее части.) быть надежным( Возможные неполадки в работе не должны нанести существенный, тем более невосполнимый, ущерб.) быть эффективным( ПО должно эффективно использовать имеющиеся ресурсы. быть удобным в использовании.ПО должно приниматься пользователями «на ура», работа должна быть удобной и естественной. Помните, что персонал, которому предстоит работать с программой, скорее всего не придет в восторг от ее появления. Постарайтесь сделать процесс обучения как можно более простым.) Какие основные проблемы стоят перед специалистами по ПО? Проблема наследования ранее созданного ПО, проблема разнородности программных систем, проблема, порожденная требованием уменьшения времени на создание ПО.
2. Буч – объектная модель - эволюция объектной модели (БИЛЕТ6) Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности. Объектно-ориентированный анализ и проектирование принципиально отличаются от традиционных подходов структурного проектирования: здесь нужно по-другому представлять себе процесс декомпозиции, а архитектура получающегося программного продукта в значительной степени выходит за рамки представлений, традиционных для структурного программирования. Отличия обусловлены тем, что структурное проектирование основано на структурном программировании, тогда как в основе объектно-ориентированного проектирования лежит методология объектно-ориентированного программирования, К сожалению, для разных людей термин "объектно-ориентированное программирование" означает разное. Ренч правильно предсказал: "В 1980-х годах объектно-ориентированное программирование будет занимать такое же место, какое занимало структурное программирование в 1970-х. но всем будет нравиться. Каждая фирма будет рекламировать свой продукт как зданный по этой технологии. Все программисты будут писать в этом стиле, причем все по-разному. Поколения языков программирования. Оглядываясь на короткую, но колоритную историю развития программирования, нельзя не заметить две сменяющих друг друга тенденции:
Большинство современных коммерческих программных систем больше и существенно сложнее, чем были их предшественники даже несколько лет тому назад. Этот рост сложности вызвал большое число прикладных исследований по методологии проектирования, особенно, по декомпозиции, абстрагированию и иерархиям. Создание более выразительных языков программирования пополнило достижения в этой области. Возникла тенденция перехода от языков, указывающих компьютеру, что делать (императивные языки), к языкам, описывающим ключевые абстракции проблемной области (декларативные языки). Вегнер сгруппировал некоторые из наиболее известных языков высокого уровня в четыре поколения в зависимости от того, какие языковые конструкции впервые в них появились: 1. SWEBOK – что это? 10 областей знаний описываемых в SWEBOK (БИЛЕТ7) Описание областей знаний в SWEBOK построено по иерархическому принципу, как результат структурной декомпозиции. Такое иерархическое построение обычно насчитывает два-три уровня детализации, принятых для идентификации тех или иных общепризнанных аспектов программной инженерии. При этом, структура декомпозиции областей знаний детализирована только до того уровня, который необходим для понимания природы соответствующих тем и возможности нахождения источников компетенции и других справочных данных и материалов. В принципе, считается, что как таковой “свод знаний” по программной инженерии представлен не в обсуждаемом руководстве (SWEBOK), а в первоисточниках (как указанных в нем, так и представленных за его рамками). SWEBOK описывает 10 областей знаний:
2. Буч – объектная модель - составные части объектного подхода (БИЛЕТ7) Дженкинс и Глазго считают, что "в большинстве своем программисты используют в работе один язык программирования и следуют одному стилю. Они программируют в парадигме, навязанной используемым ими языком. Часто они оставляют в стороне альтернативные подходы к цели, а следовательно, им трудно увидеть преимущества стиля, более соответствующего решаемой задаче" [40]. Бобров и Стефик так определили понятие стиля программирования: "Это способ построения программ, основанный на определенных принципах программирования, и выбор подходящего языка, который делает понятными программы, написанные в этом стиле" [41]. Эти же авторы выявили пять основных разновидностей стилей программирования, которые перечислены ниже вместе с присущими им видами абстракций:
1. SWEBOK: требования (БИЛЕТ8) Определение требований (Definition of a Software Requirement) – в данном случае подразумевается не процесс определения (извлечения, сбора, формирования, формулирования) требований, а дается само понятие “требования”, как такового, и отмечаются его основные характеристики, например, верифицируемость (проверяемость) требования. Требования к продукту и процессу (Product and Process Requirements) – проводится разграничение соответствующих требований как свойств продукта, который необходимо получить, и процесса, с помощью которого продукт будет создаваться; отмечается, что ряд требований может быть заложен неявно и программные требования могут порождать требования к процессу, например: работа в режиме 24x7 Функциональные и нефункциональные требования (Functional and Non-functional Requirements) – функциональные требования задают “что” система должна делать; нефункциональные – с соблюдением “каких условий” (например, скорость отклика при выполнении заданной операции); часто функциональные требования представляют в виде сценариев (вариантов использования) Use Сase. Независимые или общие свойства (Emergent Properties) – эти свойства обозначают требования, которые адресованы к системе в целом, и не могут быть соотнесены с отдельнымы ее элементами. Требования с количественной оценкой (Quantifiable Requirements) – требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием. Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО.
2.Буч – классы и объекты - природа объектов и отношения между ними (БИЛЕТ8) Отношения двух любых объектов основываются на предположениях, которыми один обладает относительно другого: об операциях, которые можно выполнять, и об ожидаемом поведении. Особый интерес для объектно-ориентированного анализа и проектирования представляют два типа иерархических соотношений объектов: · связи; · агрегация. Зайдевиц и Старк назвали эти два типа отношений отношениями старшинства и "родитель/потомок" соответственно Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины "экземпляр класса" и "объект" взаимозаменяемы. Объектно-ориентированное проектирование. Программирование прежде всего подразумевает правильное и эффективное использование механизмов конкретных языков программирования. Проектирование, напротив, основное внимание уделяет правильному и эффективному структурированию сложных систем. Мы определяем объектно-ориентированное проектирование следующим образом: Объектно-ориентированное проектирование - это методология проектирования, соединяющая в себе процесс объектной декомпозиции и приемы представления логической и физической, а также статической и динамической моделей проектируемой системы. В данном определении содержатся две важные части: объектно-ориентированное проектирование 1) основывается на объектно-ориентированной декомпозиции; 2) использует многообразие приемов представления моделей, отражающих логическую (классы и объекты) и физическую (модули и процессы) структуру системы, а также ее статические и динамические аспекты. Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного; в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами. Иногда мы будем использовать аббревиатуру OOD, object-oriented design, для обозначения метода объектно-ориентированного проектирования, изложенного в этой книге. 1. SWEBOK: техники извлечения требований (БИЛЕТ9) Существует множество практик и подходов, позволяющих добиться действительно стройной системы требований, отвечающих реальным потребностям и приоритетам заказчиков. Среди них можно выделить следующие: · Интервьюрирование – традиционный подход извлечения требований; не стоит забывать, что получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов; · Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями; · Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований; · “Разъясняющие встречи” - в оригинале звучит как “facilitated meetings”; достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п. · Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя (типовая практика в eXtreme Programming “on-site customer” – “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных бизнес-процессах;
2. Буч – классы и объекты - природа классов и отношения между ними (БИЛЕТ9) В частности, большинство объектно-ориентированных языков непосредственно поддерживают разные комбинации следующих видов отношений: · ассоциация · наследование · агрегация · использование · инстанцирование · метакласс. Понятия класса и объекта настолько тесно связаны, что невозможно говорить об объекте безотносительно к его классу. Однако существует важное различие этих двух понятий. В то время как объект обозначает конкретную сущность, определенную во времени и в пространстве, класс определяет лишь абстракцию существенного в объекте. Таким образом, можно говорить о классе "Млекопитающие", который включает характеристики, общие для всех млекопитающих. Для указания на конкретного представителя млекопитающих необходимо сказать "это - млекопитающее" или "то - млекопитающее". В общепонятных терминах можно дать следующее определение класса: "группа, множество или вид с общими свойствами или общим свойством, разновидностями, отличиями по качеству, возможностями или условиями" [17]. В контексте объектно-ориентированного анализа дадим следующее определение класса: Класс - это некое множество объектов, имеющих общую структуру и общее поведение. Любой конкретный объект является просто экземпляром класса. Что же не является классом? Объект не является классом, хотя в дальнейшем мы увидим, что класс может быть объектом. Объекты, не связанные общностью структуры и поведения, нельзя объединить в класс, так как по определению они не связаны между собой ничем, кроме того, что все они объекты. Мы можем разделить интерфейс класса на три части: · открытую (public) - видимую всем клиентам; · защищенную (protected) - видимую самому классу, его подклассам и друзьям (friends); · закрытую (private) - видимую только самому классу и его друзьям.
1. SWEBOK: проектирование (БИЛЕТ10) Процесс определения архитектуры, компонентов, интерфейсов и других характеристик системы или ее компонентов называется проектированием. Результат процесса проектирования – дизайн. Рассматриваемое как процесс, проектирование есть инженерная деятельность в рамках жизненного цикла (в данном контексте – программного обеспечения), в которой надлежащим образом анализируются требования для создания описания внутренней структуры ПО, являющейся основой для конструирования программного обеспечения как такового. Программный дизайн (как результат деятельности по проектированию) должен описывать архитектуру программного обеспечения, то есть представлять декомпозицию программной системы в виде организованной структуры компонент и интерфейсов между компонентами. Важнейшей характеристикой готовности дизайна является тот уровень детализации компонентов, который позволяет заняться их конструированием. Термины дизайн и архитектура могут использоваться взаимозаменяемым образом, но чаще говорят о дизайне как о целостном взгляде на архитектуру системы.
2. Буч – классы и объекты - взаимосвязь и качество классов и объектов (БИЛЕТ10)
|
