1. Y2 eProjects Session 4 – Advanced Topics

2. Objectives  Dynamic Models  Design Patterns (Optional)  Software testing (for S4) ACCP i7.1\Sem3_4\eProject\T4 2

3. Dynamic Models ACCP i7.1\Sem3_4\eProject\T4 Dynamic Models Use Cases State Machine Sequence Diagram Collaboration Diagram

4. Message and Message Notations  Message is drawn as a line with an arrow between sender and receiver of the message. The arrowhead indicates the type of the message sent OOAD with UML / Session 7 / 4 of 25

5. State Diagram OOAD with UML / Session 7 / 5 of 25  State diagrams are one set of diagrams which helps to draw the dynamics of a system  The state of an object at any point in time is the condition of the object at that instant  State of the object is defined by all the attributes of the object and the links maintained by it

6. State and Transition  The process of change in state is called state transition  Transitions are typically the result of the invocation of an operation that causes an important change in state  An action is something, in the case of a class it is an operation, which is invoked by/on the entity being modeled

7. Sub-state vs. composite state  The state of an object can have sub-states in it  A sub state is a part of the composite state  Sub States can be concurrent or sequential OOAD with UML / Session 7 / 7 of 25

8. OOAD with UML / Session 7 / 8 of 25 Sub-state vs. composite state (cont’d)

9. State diagram example OOAD with UML / Session 7 / 9 of 25

10. Sequence Diagram time objects A sequence diagram represents interactions between objects over the time

11. Recursion  Repetition of the same activity again and again until a condition is met  While showing recursion the event arrow comes back to the same object from where it started OOAD with UML / Session 7 / 11 of 25

12. Collaboration Diagrams  Collaboration Diagrams describes object interaction with primary focus on events not the order of interactions ( as in Sequence Diagrams)  Objects are shown using the Class icon  Sequence in Collaboration Diagram is shown by numbering the messages  Collaboration Diagrams are useful for understanding all the effects on a given object and for procedural design

13. Collaboration Diagram example

14. Usage of dynamic models  Use Sequence and\or Collaboration Diagrams: For clarifying object behaviors within a single use case Showing collaborations among the objects  Use state diagrams to look at the behavior object across use cases  For multi-threading, use activity diagrams

15. Design Patterns (Optional)  Design Patterns are common ways of structuring programs typically deal with a small number of classes, but can be of any size provide a communication framework in which ideas can be discussed at a high level can specify how objects are created, how they interact, or how they are structured ACCP i7.1\Sem3_4\eProject\T4

16. What are design patterns?  They are common ways of structuring programs typically deal with a small number of classes, but can be of any size provide a communication framework in which ideas can be discussed at a high level can specify how objects are created, how they interact, or how they are structured  Why Patterns? Reuse solutions Vocabulary for development Better software

17. Design Pattern Example Singleton Ensure a class only has one instance, and provide a global point of access to it.

18. Design Pattern Example Strategy Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it

19. Design Pattern Example Facade JDBC API DatabaseFacade Client uses Connection Statement ResultSet DatabaseMetadata ResultSetMetadata Driver … … Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

20. Design Pattern Example Data Access Object Alur et al.

21. Design Principles  Programming to interfaces not implementations  Favor composition over inheritance  Encapsulate what varies  Strive for loosely coupled between objects that interact  Classes should OPEN for extension and CLOSE for modification  Depends on abstraction, not concrete classes  Don't call us, we'll call you  A class should have only one reason to change ACCP i7.1\Sem3_4\eProject\T4

22. Best Practices  Use dynamic models to clarify main and\or complicated class relationship\algorithms, not for ‘obvious’ one  Stick to design principles for better design  Use Design Patterns ACCP i7.1\Sem3_4\eProject\T4

23. Software testing (for S4) ACCP i7.1\Sem3_4\eProject\T4

24. References and Readings  E. Gamma, R. Helm, R. Johnson, & J. Vlissides. Design Patterns: Elements of Object-Oriented Software, Addison-Wesley, 1995.  D. Alur, J. Crupi and D. Malks, Core J2EE Patterns: Best Practices and Design Strategies, 2 nd Edition, 2003  Fowler M. & Scott K., 1999, UML Distilled, Addison Wesley  Aptech India, OOAD Course, ACCP 2003 Curriculum ACCP i7.1\Sem3_4\eProject\T4