Ассоциация UML, понимая проблему
Если вы находитесь за пределами действия, то вам нужно использовать в своей функции «NameOfMyActivity.this» как действие, например:
public static void showDialog(Activity activity) {
AlertDialog.Builder builder = new AlertDialog.Builder(activity);
builder.setMessage("Your Message")
.setPositiveButton("Yes", dialogClickListener)
.setNegativeButton("No", dialogClickListener).show();
}
//Outside your Activity
showDialog(NameOfMyActivity.this);
4 ответа
Прежде всего, стрелка представляет навигационные возможности ассоциации. Одиночная стрелка означает однонаправленное отношение, в этом случае только исходный класс знает о целевом классе. Стрелка на обоих концах означает двунаправленное отношение, при котором оба класса знают друг о друге. Если стрелки отсутствуют, ассоциация может быть либо двунаправленной по умолчанию, либо подавленной для удобства чтения. На практике вам следует рисовать стрелки только тогда, когда вы хотите подчеркнуть направление ассоциации.
Когда дело доходит до вашего второго вопроса, только первый случай описывает (однонаправленную) ассоциацию между MainClass и ] OtherClass . Ни аргументы, ни возвращаемые значения не подразумевают ассоциации в смысле UML (хотя оба подразумевают зависимость). В последнем примере существует связь между классом MainClass и Something через атрибут something . Как правило, вы должны искать ассоциации в атрибутах.
Обратите внимание, что в UML существует концепция зависимости , которая представлена пунктирной линией.
Pozdrowienia!
Edit: Rewrote answer following discussion in comments (thanks to Chimp for pointing out what I overlooked in Example 4)
Example 1: OtherClass is an attribute of MainClass, and thus is modelled as an association.
Examples 2 and 3: OtherClass is referenced within the class definition, although not stored within an attribute, hence is a dependency.
Example 4: The Something class is an attribute, and therefore an association, while the referenced OtherClass, which is not stored in an attribute, and so it is dependency.
Within UML, dependencies and associations are both types of Relationship and are not strictly related (except through a common supertype), although in my opinion an association implies a dependency.
Associations are indicated by a line between the 2 classes with multiplicities at each end. Navigability is indicated by arrows showing which class is aware of which (E.g. Class A ___> Class B means A is aware of B, but not the other way around) navigability in both directions is shown by arrows at both ends. Where there is no arrows it usually safer to make no assumptions about navigability unless stated elsewhere.
Dependencies are indicated by a dashed line with an arrow from the dependant class (client) to the class being depended on (supplier) (E.g. A ----> B means A is dependant on B). Dependencies show that a class is referenced at some point, and as such the client is dependent on operations provided by the supplier, but it doesn't indicate how it is referenced (unlike an association that suggests a reference stored in an attribute).
Ассоциация представляет два или более связанных свойства.
В примере 1 MainClass имеет свойство типа OtherClass. Если OtherClass имеет явное свойство типа MainClass, тогда между классом будет двунаправленная ассоциация; если OtherClass имеет неявное свойство типа MainClass (т. е. атрибут отсутствует, но связь может быть получена путем работы в другом направлении), тогда будет однонаправленная ассоциация от MainClass к OtherClass.
В примерах 2, 3 и 4 MainClass не имеет свойств типа OtherClass. Однако он зависит от OtherClass, поэтому между MainClass и OtherClass будет связь зависимости. В коде это представлено с использованием или #include .
Обычно я использую два разных соединителя в UML:
Когда класс зависит от реализации другого. Это означало бы, что один класс создает или обрабатывает экземпляр другого. Таким образом, вызывающий класс зависит от класса реализации. Это будет очевидно во всех ваших примерах.
Когда класс расширяет или реализует другой.