1 / 18

Software Architecture In Practice

Software Architecture In Practice. Chapters 1-3 Architecture Business Cycle Structures. Architecture Business Cycle. Organization affects software architecture Software architecture affects organization Experience, training, industry standard, competitive pressure, ambition, stability.

liesel
Download Presentation

Software Architecture In Practice

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. Software Architecture In Practice Chapters 1-3 Architecture Business Cycle Structures CS527 - lecture 4

  2. Architecture Business Cycle • Organization affects software architecture • Software architecture affects organization • Experience, training, industry standard, competitive pressure, ambition, stability CS527 - lecture 4

  3. Domain model vs. transaction script • How to make middle tier of 3-tier system • Design OO domain model, translate to RDBMS. Top layer sees only objects. Objects do not know about SQL. • Transaction script is a procedure that includes SQL to manipulate tables. Top layer calls procedures. CS527 - lecture 4

  4. Architecture on Organization? • Maintainability • Ability to move into new lines of business • Ability to run on important platforms • Ease of learning by new employees • Generalists or specialists? • Require architect CS527 - lecture 4

  5. Structures • The software architecture of a computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of these elements, and the relationships among them. CS527 - lecture 4

  6. A-7E • Three important structures: • Module decomposition • Submodules, shares a secret • Uses • One procedure calls another • Processes • Synchronization, shares CPU, utilization CS527 - lecture 4

  7. A-7E • Time-triggered – each process allowed to run every so often and given a time budget • Polling, not event driven • Each process uses a known fraction of CPU • Kind of dataflow CS527 - lecture 4

  8. A-7E velocity sensor button location sensor target actuator CS527 - lecture 4

  9. Toy Bank • Money market accounts • Loans • Transfer between accounts and to other banks • Accounting / customer management • Different currencies – currency exchange CS527 - lecture 4

  10. Three-tier architecture Presentation Service Layer Business Logic Domain Model Data source CS527 - lecture 4

  11. Technologies • Java – J2EE but POJO, not EJB • Hibernate and MySQL for persistence • Tomcat and struts for web interface CS527 - lecture 4

  12. Organization • Eight teams of 2-4 people. • Group 1 made an initial version, “to define the architecture”. Other groups extended the system. • Groups tried to be independent of each other to ensure getting their code to run. • Little consistency. CS527 - lecture 4

  13. Directory (code) structure • services/src/java/edu/uiuc/toybank • group1, general ledger, core, loan, cmm • subsystems/src/java/edu/uiuc/toybank • general ledger, loan origination, bank transfer • webapp/src/java/edu/uiuc/toybank • federalreserve/src/java/edu/uiuc/toybank CS527 - lecture 4

  14. Inconsistent use of Hibernate • Group1 • DTO and DAO – used DAO instead of domain model • CMM • Real domain model, empty DTO and DAO directories, but has a “mapper” • Loan, loan orgination • Real domain model, no DTO or DAO, no mapper CS527 - lecture 4

  15. Duplication in domain model • Duplicate versions of Account, Customer, Loan • Some groups built a specialized version rather than use the more general one • Sometimes the class was different, but the name was the same CS527 - lecture 4

  16. Results • No standard way of doing things • Hard to find code • Hard to read code • Hard to tell what works CS527 - lecture 4

  17. Back to SAIP • Architectural patterns • Reference models • Reference architectures • Architecture CS527 - lecture 4

  18. Conclusion • Same patterns is not enough, need a consistent architecture CS527 - lecture 4

More Related