Форум Сообщества Аналитиков
Общий раздел => Теория моделирования и нотации => UML SysML и пр. => Тема начата: litvinenko от 10 Января 2007, 03:33:20
-
Извините, может быть надо было куда-то в другое место писать - если так - перенесите куда надо :)
Так вот.
Вот хоть убейте, не могу понять, что такое класс-сущность, граничный класс и т.п.
Можно на конкретных примерах пояснить?
Буду очень благодарен.
Спасибо.
-
Извините, может быть надо было куда-то в другое место писать - если так - перенесите куда надо :)
Так вот.
Вот хоть убейте, не могу понять, что такое класс-сущность, граничный класс и т.п.
Можно на конкретных примерах пояснить?
Буду очень благодарен.
Спасибо.
В подходе BCE (Boundary-Controller-Entity):
Entity (Класс-сущность) - отвечает за хранение информации по объекту-сущности, например такому, как "Заказ" и содержит методы, соответствующие его бизнес-логике, типа добавить строку заказа, завершить заказ и т.д.
Boundary (пограничный класс) - отвечает за организацию взаимодействия с субъектом (actor). В оконных приложениях это грубо говоря, класс окна.
Controller (управляющий класс) - отвечает за передачу запросов от Boundary нужным классам Entity и возвращает ему результаты. Грубо говоря, Контроллер заказа "дёргает" методы Заказа, и получив ответ, обновляет Окно (+ может делать множество других операций, связанных с другими сущностями ПрОбл и Приложения, типа логирования). Т.е. он отвечает в том числе за Логику Приложения (в отличие от Бизнес-Логики), если нет отдельного слоя Логики Приложений, например, отсечённого от Контроллера Сервисным слоем.
В настольном приложении все классы реализуются в компоненты, находящиеся на данной машине. В клиент-серверных приложениях если клиент толстый, то B и C находится на клиенте, а E - скорее всего на сервере. Если клиент тонкий, то в принципе вся связка BCE находится на серверной стороне, причём эти классы могут быть распределены по разным физическим серверам (по крайней мере BC отдельно от E).
Вот ещё примерчик (http://www.intuit.ru/department/se/ibmrrose/8/4.html) для неоконного приложения, в котором граничными классами выступают устройства чтения карты и клавиатура.
Подробнее об этом можно почитать, например, у Мацящека (http://www.wmate.ru/ebooks/book249.html).
Вообще мне этот подход кажется довольно спорным, т.к. имхо аналитик не должен заниматься проектированием системы, если эти функции разделены по людям, т.к. иначе потом придёт архитектор и окажется, что он всё реализует иначе, исходя из неФ-требований, и работа анлитика идёт коту под хвост.
-
Андрей. Ну какие еще вам примеры нужны.
Класс-сущность - это нечто относящееся к предметной области, несто, что возможно будете хранить в долговременной памяти. Например: Лекции, Тесты, Студенты, Преподаватели, Персона, Дисциплина, и т.п. - Обычно для каждого такого класса создают таблицу в БД.
Граничные классы располагаются на ГРАНИЦЕ системы и внешней среды. Это формы, отчеты, интерфейсы к аппаратуре, другим системам
У вас ООП было? В чем программировали? Наверняка формы делали - а что такое форма, как не класс с определенными характеристиками, событиями и прочее.
-
У вас ООП было? В чем программировали? Наверняка формы делали - а что такое форма, как не класс с определенными характеристиками, событиями и прочее.
Ну, Delphi было, но мало :)
Сейчас PHP5 используем на работе.
Так. Ну я кажется понял :)
-
Стоп, Вы студент, или работник? Ничего не понял?
Но все равно, даже в РНР5 можно увидеть эти граничные классы - совсем несложно создать объект который формирует часть HTML страницы, например форму авторизации.
Так вообщем-то и сделано в cms-ках многих
-
Стоп, Вы студент, или работник? Ничего не понял?
Но все равно, даже в РНР5 можно увидеть эти граничные классы - совсем несложно создать объект который формирует часть HTML страницы, например форму авторизации.
Так вообщем-то и сделано в cms-ках многих
Я и тот и другой :)
Учусь на пятом курсе, пишу диплом. И работаю. В данный момент занимаюсь MySQL
А все это затеял для диплома.
-
<?php
class UserForm
{
public name;
public lastname;
...
public submit;
public function __construct()
{
$this->name = "<input type=text name=name>";
$this->lastname = "<input type=text name=lastname>";
...
$this->submit = "<input type=submit value='Register'>";
}
public function showForm()
{
echo "<table>";
echo "<tr><td>Name:</td>"; echo "<td>".$this->name."</td>"; echo "</tr>";
echo "<tr><td>Last Name:</td>"; echo "<td>".$this->lastname."</td>"; echo "</tr>";
echo "<tr><td colspan=2>.$this->submit."</td>"; echo "</tr>";
echo "</table>";
}
}
?>
Это что-то типа такого класса, что ли? %)
-
ну да
-
А в этом что-то есть. Никогда как-то не сталкивался с таким...
Только вот думаю, что для малокого количества людей в разработке - это нормально, где программист является и дизайнером и верстальщиком...
А вот например в большой группе людей, например верстальщик. который ничего не смыслит в программировании - будет трудно понятно что здесь и как.
Не лучше ли просто использовать какие-то темплейты, которые будут вставляться в те места, которые надо?
-
так. исходя из моего прошлого примера, где я соображал, что такое граничный класс,
попробую изобразить класс-сущность
<?php
class User
{
public name;
public lastname;
...
public function __construct($name, $lastname, ...)
{
$this->name = $name;
$this->lastname = $lastname;
...
}
public function getName()
{
return this->name;
}
...
...
...
}
?>
Я иду в правильном направлении?
-
Да, конечно. Класс-сущность отображает предметную область.
Насчет верстальщика и программера.
Что такое верстальщик - это все-таки не совсем просто дизайнер. Просто дизайнер - это фактически художник, который рисует вам дизайн в Photoshop к примеру. А верстальщик уже идею дизайнера воплощает в шаблон. А шаблон будет использовать html-коды - это уже разметка, это уже программа, css-стили, а это тоже требует ясного представления о сути проблемы.
Классическая архитектура приложения: логика представления(1 слой), бизнес-логика или программная логика работы системы(2 слой), логика данных скажем(или 3 уровень хранение данных).
Посмотрим как это зачастую реализуется например в Delphi:
Скажем есть база данных.
В приложении мы делаем: уровень подключение к БД - типа DataBaseConnection Transaction
Далее формируем DataSet - класс для доступа к набору данных и манипуляции с ним
DataSource - класс связывающийся с DaTaSet и фактически преобразующий сущности БД в сущности программы и не посредственно соединяется с элементами DataControl - поля, списки, гриды и тп.
Вы можете делать так, а можете и по другому. Можно все реализовать на классах, а можно все сделать на функциях, что эффективнее и проще?
-
Так. Ну вот с граничным классом и классом сущностью я разобрался. Остался третий класс - контроллер, да?
Это например будет класс, где есть куча методов, которые работают с классом User.
Например метод RegisterUser или UpdateUserInfo, так?
-
Необязательно только с юзером, В моем примере, который я привел ранее - это классы скажем DatBaseConnection, т.е. классы которые исполняют какие-то общие действия. Например классы без состояния.
Скажем в коде рнр это мог бы быть например класс доступа к БД (соединение, выбор бд, выполнение запроса, возвращение данных, закрытие соединения с сервером) Примерно так.
Т.е. например у вас есть ссылка - показать список преподавателей. Каков цикл действия может быть? Вызов класса отвечающего за соединение БД, вызов класса выполняющего запрос и подгтовку данных, вызов класса формирующего шаблон отображения. Т.е. классы управляющие (control) работой других, помогающие другим и прочее.
Все это связано с архитектурой или моделью MVC. В вашем случае, может конечно будет так, что никакого реального деления классов и не будет, однако такой подход позволяет делать повторно используемый код и т.п.
Ну посмотрите на библиотеку PEAR или шаблоны SMARTY или FASTTEMPLATE... Надеюсь объяснил? Если нет попробуйте почитать здесь http://www.intuit.ru/department/pl/umlbasics/5/
-
Да, спасибо большое за разъяснения. теперь мне все понятно. Впринципе я что-то такое и думал в самом начале, просто наверно не мог сформулировать.
Спасибо большое.
-
На здоровье, Андрей.
Очень рад, если сумел что-то объяснить и чем-то помочь.
Надеюсь, выполнив свой проект, Вы:
1. Опубликуете его, как пример для обсуждения и подражания
2. Не потеряете контакта с нашим ресурсом
3. Научите нас в будущем чему-то интересному
-
Да, конечно!
Я тут немного с ним затормозился, так как сессия, экзамены и все такое :)
А вообще недавно меня еще в аспирантуру позвали, так что вполне вероятно, что я буду развивать этот проект и дальше.