1. OOAD – III Software Design Nupul Kukreja 10 th October, 2014

3. Agenda Technical Architecture (TA) – What? – Good TA – Winbook TA – Why/When? Detailed Design – What/How? – Sequence Diagrams (SD) What/Why? How? Hands on In class – Robustness Diagram – High level SD – Low level SD Conclusion

4. TECHNICAL ARCHITECTURE Diving Deeper

5. Main program and sub-routines Object-oriented Language Influenced Virtual Machine Client-Server Layered Batch-sequential Pipe-and-filter Dataflow Styles Blackboard Rule-based Shared Memory Publish/Subscribe Event-based Implicit Invocation Interpreter Mobile code Interpreter Representational State Transfer (e.g. WWW) REST (e.g. Gnutella, Skype, Napster etc.,) Peer-to-Peer

6. Twin Peaks: Requirements and Architecture RequirementsArchitecture General Detailed Level of Detail Implementation Dependence IndependentDependent

7. Good Technical Architecture Built to satisfy business and level of service requirements of the system Describes: – Deployment model (topology, servers etc.,) – Package/component model (separation of concerns) – Data Model (ER diagram etc.,) Addresses –ilities effectively (i.e., scalability, security, availability etc.,) Testable Shows external systems to be interfaced with Increase confidence of “being right”

8. Client: HTML/JS Presentation Layer: Tomcat/Restlet Data Access Layer: Spring/JDBC Database

10. Technical Architecture – When & Why? Done much before robustness analysis – In parallel to/before requirements negotiation – Refined as more learned about system You must know the high-level “how” to derive the low/design-level “how” – Allocating methods to classes – Which classes/services to involve? – Which methods to call and in what order? – To think about the code before coding it

11. SEQUENCE DIAGRAMMING Diving into design

12. Detailed OOD Domain modeling, use-case and robustness analysis  discovering “classes” Detailed design  “allocating” behavior i.e., allocating methods to classes Works within the technical architecture defined Reifies our initial guess of how classes really interact with each other Sequence diagrams are “one” way to drive detailed design – Use case  Robustness  Sequence Diagram

13. Sequence Diagram Notation

14. “Why” Sequence Diagramming Allocate behavior to classes – Controllers  operations on classes or separate controller objects Show detailed interaction among classes over lifetime of use-case – “how” do objects communicate to realize use case Finalize distribution of operations among classes – Who’s doing what and to whom?

15. “How” to do it? Start from where you left off with Robustness Analysis (RA) – One sequence diagram per use case 1.Copy the correct, detailed & explicit use case text to SD 2.Copy entity objects from RA diagram to SD 3.Copy boundary objects and actors from RA diagram to SD 4.Assign operations to classes (actual thinking work)

16. HANDS ON EXERCISE

18. A user enters the their email id and password on the login page. The system checks if the user is registered by validating their account against the set of registered users. If the user is registered he is taken to the page showing the list of projects Alternative course: -Invalid login/ password: The system displays invalid username/ password

19. Blank 1

20. Blank 2

21. Reiteration of Steps 1.Create an initial high level OO sequence diagram only involving boundary/entity objects from RA diagram 2.Add implementation level details/classes to sequence diagram – Allocate/call appropriate framework methods 3.Review SD to validate correctness 4.Update static class diagram with implementation classes and identified methods 5.Repeat for each use case 6.Move to coding after thorough reviewing 7.Update SD as you identify gaps in design  rarely done  documentation obsolete  Architectural degradation