WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 10 | 11 || 13 | 14 |   ...   | 16 |

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

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

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

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

- 92 - УМП «Автоматизированные методы разработки архитектуры ПО» o Имеются отношения между самими кооперациями. Кооперации могут уточнять описания других коопераций, что может быть смоделировано в виде отношения уточнения. Отношения уточнения между кооперациями обычно отражают отношения уточнения, существующие между представленными ими прецедентами.

Кооперации могут группироваться в пакеты. Обычно к этому приходится прибегать только при моделировании очень больших систем.

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

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

- 93 - УМП «Автоматизированные методы разработки архитектуры ПО» Моделирование реализации прецедента состоит из следующих этапов:

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

o Организуйте эти структурные элементы в диаграмму классов.

o Рассмотрите отдельные сценарии, которые представляют данный прецедент. Каждый сценарий описывает один из путей прохождения прецедента.

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

o Организуйте эти структурные и поведенческие элементы как кооперацию, которую вы можете соединить с прецедентом через реализацию.

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

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

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

- 94 - УМП «Автоматизированные методы разработки архитектуры ПО» Моделирование реализации операции осуществляется так:

o Идентифицируйте параметры, возвращаемое значение и другие объекты, видимые для операции.

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

o Если операция алгоритмически сложна, смоделируйте ее реализацию с помощью диаграммы деятельности.

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

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

Механизмы (Mechanisms) – это автономные кооперации, контекстом которых является система в целом. Любой элемент, видимый в некоторой части системы, является кандидатом на участие в механизме.

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

Моделирование механизмов осуществляется следующим образом:

- 95 - УМП «Автоматизированные методы разработки архитектуры ПО» o Идентифицируйте основные механизмы, образующие архитектуру системы Их выбор диктуется общим архитектурным стилем, который вы решили положить в основу своей реализации, а также стилем, наиболее отвечающие предметной области.

o Представьте каждый механизм в виде кооперации.

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

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

- 96 - УМП «Автоматизированные методы разработки архитектуры ПО» Приложение 2. Текст исходного кода контейнера string библиотеки STL Лучшим учебным материалом для изучения техники прграммирования являются исходные тексты кода программного обеспечения, написанные великими программистами.

Приведенный ниже исходный код контейнера string билиотеки стандартных шаблонов STL – это лишь часть легендарной разработки, созданной Александром Степановым.

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

- 97 - УМП «Автоматизированные методы разработки архитектуры ПО» Ниже приведён исходный код контейнера string20.

/* * Copyright (c) 1997- * Silicon Graphics Computer Systems, Inc.

* * Permission to use, copy, modify, distribute and sell this software * and its documentation for any purpose is hereby granted without fee, * provided that the above copyright notice appear in all copies and * that both that copyright notice and this permission notice appear * in supporting documentation. Silicon Graphics makes no * representations about the suitability of this software for any * purpose. It is provided "as is" without express or implied warranty.

*/ #ifndef SGI_STL_STRING #define SGI_STL_STRING #include #include #include #include #include #include #include #include #include #ifdef STL_USE_NEW_IOSTREAMS #include #else /* STL_USE_NEW_IOSTREAMS */ #include #endif /* STL_USE_NEW_IOSTREAMS */ // Standard C++ string class. This class has performance // characteristics very much like vector<>, meaning, for example, that // it does not perform reference-count or copy-on-write, and that // concatenation of two strings is an O(N) operation.

// There are three reasons why basic_string is not identical to // vector. First, basic_string always stores a null character at the // end; this makes it possible for c_str to be a fast operation.

// Second, the C++ standard requires basic_string to copy elements // using char_traits<>::assign, char_traits<>::copy, and // char_traits<>::move. This means that all of vector<>'s low-level // operations must be rewritten. Third, basic_string<> has a lot of // extra functions in its interface that are convenient but, strictly // speaking, redundant.

// Additionally, the C++ standard imposes a major restriction: according // to the standard, the character type _CharT must be a POD type. This // implementation weakens that restriction, and allows _CharT to be a // a user-defined non-POD type. However, _CharT must still have a // default constructor.

STL_BEGIN_NAMESPACE #if defined(sgi) && !defined(GNUC) && (_MIPS_SIM != _MIPS_SIM_ABI32) #pragma set woff #pragma set woff #endif // A helper class to use a char_traits as a function object.

template struct _Not_within_traits : public unary_function { typedef const typename _Traits::char_type* _Pointer;

const _Pointer _M_first;

const _Pointer _M_last;

Исходные тексты STL взяты из официального источника http://www.sgi.com/tech/stl/download.html посредством свободного скачивания и представляют собой авторский код, написанный Александром Степановым. Приведенный здесь код имеет статус Copyright (c) 1996 Silicon Graphics Computer Systems, Inc. и приведен в виде “как есть”.

- 98 - УМП «Автоматизированные методы разработки архитектуры ПО» _Not_within_traits(_Pointer f, _Pointer l) : _M_first(f), _M_last(l) {} bool operator()(const typename _Traits::char_type& x) const { return find_if(_M_first, _M_last, bind1st(_Eq_traits<_Traits>(), x)) == _M_last;

} };

// ------------------------------------------------------------ // Class _String_base.

// _String_base is a helper class that makes it it easier to write an // exception-safe version of basic_string. The constructor allocates, // but does not initialize, a block of memory. The destructor // deallocates, but does not destroy elements within, a block of // memory. The destructor assumes that _M_start either is null, or else // points to a block of memory that was allocated using _String_base's // allocator and whose size is _M_end_of_storage - _M_start.

// Additionally, _String_base encapsulates the difference between // old SGI-style allocators and standard-conforming allocators.

#ifdef STL_USE_STD_ALLOCATORS // General base class.

template class _String_alloc_base { public:

typedef typename _Alloc_traits<_Tp, _Alloc>::allocator_type allocator_type;

allocator_type get_allocator() const { return _M_data_allocator; } _String_alloc_base(const allocator_type& a) : _M_data_allocator(a), _M_start(0), _M_finish(0), _M_end_of_storage(0) {} protected:

_Tp* _M_allocate(size_t n) { return _M_data_allocator.allocate(n); } void _M_deallocate(_Tp* p, size_t n) { if (p) _M_data_allocator.deallocate(p, n);

} protected:

allocator_type _M_data_allocator;

_Tp* _M_start;

_Tp* _M_finish;

_Tp* _M_end_of_storage;

};

// Specialization for instanceless allocators.

template class _String_alloc_base<_Tp,_Alloc,true> { public:

typedef typename _Alloc_traits<_Tp, _Alloc>::allocator_type allocator_type;

allocator_type get_allocator() const { return allocator_type(); } _String_alloc_base(const allocator_type&) : _M_start(0), _M_finish(0), _M_end_of_storage(0) {} protected:

typedef typename _Alloc_traits<_Tp, _Alloc>::_Alloc_type _Alloc_type;

_Tp* _M_allocate(size_t n) { return _Alloc_type::allocate(n); } void _M_deallocate(_Tp* p, size_t n) { _Alloc_type::deallocate(p, n); } protected:

_Tp* _M_start;

_Tp* _M_finish;

_Tp* _M_end_of_storage;

};

template class _String_base : public _String_alloc_base<_Tp, _Alloc, _Alloc_traits<_Tp, _Alloc>::_S_instanceless> { - 99 - УМП «Автоматизированные методы разработки архитектуры ПО» protected:

typedef _String_alloc_base<_Tp, _Alloc, _Alloc_traits<_Tp, _Alloc>::_S_instanceless> _Base;

typedef typename _Base::allocator_type allocator_type;

void _M_allocate_block(size_t n) { if (n <= max_size()) { _M_start = _M_allocate(n);

_M_finish = _M_start;

_M_end_of_storage = _M_start + n;

} else _M_throw_length_error();

} void _M_deallocate_block() { _M_deallocate(_M_start, _M_end_of_storage - _M_start); } size_t max_size() const { return (size_t(-1) / sizeof(_Tp)) - 1; } _String_base(const allocator_type& a) : _Base(a) { } _String_base(const allocator_type& a, size_t n) : _Base(a) { _M_allocate_block(n); } ~_String_base() { _M_deallocate_block(); } void _M_throw_length_error() const;

void _M_throw_out_of_range() const;

};

#else /* STL_USE_STD_ALLOCATORS */ template class _String_base { public:

typedef _Alloc allocator_type;

allocator_type get_allocator() const { return allocator_type(); } protected:

typedef simple_alloc<_Tp, _Alloc> _Alloc_type;

_Tp* _M_start;

_Tp* _M_finish;

_Tp* _M_end_of_storage;

// Precondition: 0 < n <= max_size().

_Tp* _M_allocate(size_t n) { return _Alloc_type::allocate(n); } void _M_deallocate(_Tp* p, size_t n) { if (p) _Alloc_type::deallocate(p, n);

} void _M_allocate_block(size_t n) { if (n <= max_size()) { _M_start = _M_allocate(n);

_M_finish = _M_start;

_M_end_of_storage = _M_start + n;

} else _M_throw_length_error();

} void _M_deallocate_block() { _M_deallocate(_M_start, _M_end_of_storage - _M_start); } size_t max_size() const { return (size_t(-1) / sizeof(_Tp)) - 1; } _String_base(const allocator_type&) : _M_start(0), _M_finish(0), _M_end_of_storage(0) { } _String_base(const allocator_type&, size_t n) : _M_start(0), _M_finish(0), _M_end_of_storage(0) { _M_allocate_block(n); } ~_String_base() { _M_deallocate_block(); } void _M_throw_length_error() const;

void _M_throw_out_of_range() const;

};

- 100 - УМП «Автоматизированные методы разработки архитектуры ПО» #endif /* STL_USE_STD_ALLOCATORS */ // Helper functions for exception handling.

template void _String_base<_Tp,_Alloc>::_M_throw_length_error() const { STL_THROW(length_error("basic_string"));

} template void _String_base<_Tp, _Alloc>::_M_throw_out_of_range() const { STL_THROW(out_of_range("basic_string"));

} // ------------------------------------------------------------ // Class basic_string.

// Class invariants:

// (1) [start, finish) is a valid range.

// (2) Each iterator in [start, finish) points to a valid object // of type value_type.

// (3) *finish is a valid object of type value_type; in particular, // it is value_type().

// (4) [finish + 1, end_of_storage) is a valid range.

Pages:     | 1 |   ...   | 10 | 11 || 13 | 14 |   ...   | 16 |






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.