notes:swen30006
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| notes:swen30006 [2021/05/24 01:26] – created joeleg | notes:swen30006 [2023/05/30 22:32] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 14: | Line 14: | ||
| ===== Domain model ===== | ===== Domain model ===== | ||
| - | {{dom1.png}} | + | {{ dom1.png?100}} |
| Model as an overview of the system. | Model as an overview of the system. | ||
| Line 33: | Line 33: | ||
| ==== Sequence diagram ==== | ==== Sequence diagram ==== | ||
| - | {{seq1.png}} | + | {{ seq1.png?100}} |
| Shows the sequence of events in an interaction between classes. | Shows the sequence of events in an interaction between classes. | ||
| ==== Design class diagram (Static model) ==== | ==== Design class diagram (Static model) ==== | ||
| - | {{des1.png}} | + | {{ des1.png?100}} |
| Shows a software level relationship between classes. | Shows a software level relationship between classes. | ||
| Line 75: | Line 75: | ||
| ===== Creator ===== | ===== Creator ===== | ||
| - | {{create-seq.png}} | + | {{ create-seq.png?100}} |
| - | {{create-des.png}} | + | {{ create-des.png?100}} |
| Who should be responsible for creating a new instance of some class? | Who should be responsible for creating a new instance of some class? | ||
| Line 93: | Line 93: | ||
| ===== Information Expert ===== | ===== Information Expert ===== | ||
| - | {{infexp.png}} | + | {{ infexp.png?100}} |
| What is a general principle of assigning responsibilities to objects? | What is a general principle of assigning responsibilities to objects? | ||
| Line 176: | Line 176: | ||
| ====== State Machines ====== | ====== State Machines ====== | ||
| - | {{state1.png}} | + | {{ state1.png?100}} |
| State machines describe the behaviour of an object in terms of events that affect the object and the state of the object between events. | State machines describe the behaviour of an object in terms of events that affect the object and the state of the object between events. | ||
| Line 193: | Line 193: | ||
| ===== Choice pseudostates ===== | ===== Choice pseudostates ===== | ||
| - | {{statechoice.png}} | + | {{ statechoice.png?100}} |
| Used to when the same trigger will transition to different states depending on the guard. | Used to when the same trigger will transition to different states depending on the guard. | ||
| Line 207: | Line 207: | ||
| ===== Adapter ===== | ===== Adapter ===== | ||
| - | {{adapter.png}} | + | {{ adapter.png?100}} |
| How to resolve incomplete interfaces, or provide a stable interface to similar components with different interfaces? | How to resolve incomplete interfaces, or provide a stable interface to similar components with different interfaces? | ||
| Line 230: | Line 230: | ||
| ===== Singleton ===== | ===== Singleton ===== | ||
| - | {{singleton.png}} | + | {{ singleton.png?100}} |
| Exactly one instance of a class is allowed - it is a singleton. Objects need a global and single point of access. | Exactly one instance of a class is allowed - it is a singleton. Objects need a global and single point of access. | ||
| Line 239: | Line 239: | ||
| ===== Strategy ===== | ===== Strategy ===== | ||
| - | {{strategy.png}} | + | {{ strategy.png?100}} |
| Line 247: | Line 247: | ||
| ===== Composite ===== | ===== Composite ===== | ||
| - | {{composite.png}} | + | {{ composite.png?100}} |
| How to treat a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object? | How to treat a group or composition structure of objects the same way (polymorphically) as a non-composite (atomic) object? | ||
| Line 253: | Line 253: | ||
| ===== Facade ===== | ===== Facade ===== | ||
| - | {{facade.png}} | + | {{ facade.png?100}} |
| Line 266: | Line 266: | ||
| ===== Observer ===== | ===== Observer ===== | ||
| - | {{observer.png}} | + | {{ observer.png?100}} |
| Different kinds of subscriber objects are interested in the state of changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. | Different kinds of subscriber objects are interested in the state of changes or events of a publisher object, and want to react in their own unique way when the publisher generates an event. | ||
| Line 275: | Line 275: | ||
| ===== Decorator ===== | ===== Decorator ===== | ||
| - | {{decorator.png}} | + | {{ decorator.png?100}} |
| How to dynamically add behaviour or state to individual objects at run time without changing the interface presented to the client? | How to dynamically add behaviour or state to individual objects at run time without changing the interface presented to the client? | ||
notes/swen30006.1621819610.txt.gz · Last modified: 2023/05/30 22:32 (external edit)