1 / 21

OOAD – III Software Design

OOAD – III Software Design. Nupul Kukreja 10 th October, 2014. 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.

shafira-sears
Download Presentation

OOAD – III Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. Diving Deeper Technical Architecture

  4. Twin Peaks: Requirements and Architecture General Requirements Architecture Level of Detail Detailed Implementation Dependence Independent Dependent

  5. 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”

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

  7. 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

  8. Diving into design Sequence Diagramming

  9. 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

  10. Sequence Diagram Notation

  11. “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?

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

  13. Hands on exercise

  14. 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

  15. Blank 1

  16. Blank 2

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

More Related