Методические указания по выполнению практических работ по профессиональному модулю
жүктеу/скачать 5.65 Mb.
|
| Ход работы
1. Изучить теоретические положения. 2. Выписать программные компоненты рассмотренной системы авиасимулятора. 3. Предложить архитектуру программы для расчета заработной платы работникам предприятия: Предприятие имеет три подразделения: управление, производственный отдел, обеспечивающий отдел. Начисление заработной платы работникам отдела управления производится в соответствии с табелем учета рабочего времени, составляемого специалистом отдела кадров из отдела управления. Начисление заработной платы работникам производственного отдела выполняется за фактически выполненную работу (количество произведенной продукции) и с учетом отработанных часов, учитываемых табельщиком. Заработная плата работников обеспечивающего отдела зависит от КТУ (коэффициент трудового участия) каждого работника этого отдела. КТУ вычисляется начальником отдела обеспечения и зависит от объема продукции, выпущенной производственным отделом и должности работника. Кроме перечисленных факторов на размер заработной платы всех работников, влияют стаж работы, образование и занимаемая должность работника (сведения ежемесячно предоставляются начальником отдела кадров) Возможные шаги разработки архитектуры программы могут состоять в следующем: 1. Выделение компонентов a. Выбирается набор «основных» сценариев использования — наиболее существенных и выполняемых чаще других. b. Исходя из опыта проектировщиков, выбранного архитектурного стиля (см. следующую лекцию) и требований к переносимости и удобству сопровождения системы определяются компоненты, отвечающие за определенные действия в рамках этих сценариев, т.е. за решение определенных подзадач. c. Каждый сценарий использования системы представляется в виде последовательности обмена сообщениями между полученными компонентами. d. При возникновении дополнительных хорошо выделенных подзадач добавляются новые компоненты, и сценарии уточняются. 2. Определение интерфейсов компонентов a. Для каждого компонента в результате выделяется его интерфейс — набор сообщений, которые он принимает от других компонентов и посылает им. b. Рассматриваются «неосновные» сценарии, которые так же разбиваются на последовательности обмена сообщениями с использованием, по возможности, уже определенных интерфейсов. c. Если интерфейсы недостаточны, они расширяются. d. Если интерфейс компонента слишком велик, или компонент отвечает за слишком многое, он разбивается на более мелкие. 3. Уточнение набора компонентов a. Там, где это необходимо в силу требований эффективности или удобства сопровождения, несколько компонентов могут быть объединены в один. b. Там, где это необходимо для удобства сопровождения или надежности, один компонент может быть разделен на несколько. 4. Достижение нужных свойств. Все это делается до тех пор, пока не выполнятся следующие условия: a. Все сценарии использования реализуются в виде последовательностей обмена сообщениями между компонентами в рамках их интерфейсов. b. Набор компонентов достаточен для обеспечения всей нужной функциональности, удобен для сопровождения и импортирования на другие платформы и не вызывает заметных проблем производительности. c. Каждый компонент имеет небольшой и четко очерченный круг решаемых задач и строго определенный, сбалансированный по размеру интерфейс. жүктеу/скачать 5.65 Mb. Достарыңызбен бөлісу:
|