Sen2 Architectural Design

957 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
957
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
35
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Sen2 Architectural Design

  1. 1. Architectural Design Fontys University of Applied Sciences Group 4
  2. 2. Overview <ul><li>Introduction
  3. 3. Architectual desicions
  4. 4. System Organisation
  5. 5. Decomposition
  6. 6. Control types
  7. 7. Conclusuion </li></ul>
  8. 8. Introduction <ul><li>First Design </li><ul><li>Communication with Project team
  9. 9. System analysis </li><ul><li>Performance
  10. 10. Access protection
  11. 11. Security
  12. 12. Availability
  13. 13. Maintenance </li></ul></ul></ul>
  14. 14. Architectural desicion <ul><li>Fundamental questions </li><ul><li>Is there already a pattern for that problem?
  15. 15. What architectual styles are suiteable ?
  16. 16. How could we divide in Subsystems and modules ?
  17. 17. Wich strategy is suitable to control the system ?
  18. 18. How could we evaluate our System ? </li></ul></ul>
  19. 19. Architectural decission : Subsystem <ul><li>Subsytem models </li><ul><li>Static model
  20. 20. Dynamic process model
  21. 21. Interface model
  22. 22. Relation model
  23. 23. Distribution model </li></ul></ul>
  24. 24. System Organisations Overview <ul><li>Reflects the basic strategy that is used to structure a system
  25. 25. patterns of system organization
  26. 26. Three popular structures </li><ul><li>repository model
  27. 27. client/server model
  28. 28. layered style model </li></ul><li>Maybe more than one structure is used in a software system
  29. 29. described in ADL, UML or Box-diagrams </li></ul>
  30. 30. System Organisation: repository model <ul><li>Usage of central database
  31. 31. Single database per subsystem ( de-central ) </li><ul><li>Sharing data by sending messages </li></ul></ul><ul>Pros: <li>Large amount of data
  32. 32. Centralised backup, protection, access control, data recovery
  33. 33. Efficient way of sharing data </li></ul><ul>Cons: <li>Subsystems needs to fit into data save model
  34. 34. Subsystems maybe have other requirements (e.g. other kind of access control) </li></ul>
  35. 35. System Organisation: client/server <ul><li>System of multiple services and server
  36. 36. Multiple clients are using services
  37. 37. Remote procedure calls (RPC, network communication) </li></ul><ul>Pros: <li>Shared architecture
  38. 38. Large amount of different services
  39. 39. Increase reliability
  40. 40. Easy to add servers and services </li></ul><ul>Cons: <li>No combined data model
  41. 41. Subsystems are organising data in different ways
  42. 42. contingency risk
  43. 43. Redundant server management costs </li></ul>
  44. 44. System Organisation: layered style <ul><li>Divide system into multiple layers
  45. 45. 3 tier architecture (client, application-server, data-server)
  46. 46. OSI reference model </li></ul><ul>Pros: <li>Incremental developing of systems
  47. 47. Easy to extend and to modify
  48. 48. Security
  49. 49. Testability </li></ul><ul>Cons: <li>Performance, redundancy calls
  50. 50. add overhead and latency to the processing of data </li></ul>
  51. 53. Decomposition Subsystem vs. Modul <ul><li>Subsystem : </li><ul><li>Independent System wich operations are not based on other subsystems
  52. 54. Include modules
  53. 55. Interfaces for communication with other subsystems </li></ul><li>Modul : </li><ul><li>Part of a Subsystem ( System component )
  54. 56. Provides services to other components
  55. 57. Normaly not considered as a seperate system </li></ul></ul>
  56. 58. Decomsposition <ul><li>Partitioning </li><ul><li>Objectoriented </li><ul><li>Differ a System in communicating Objects </li></ul><li>Function oriented Pipeline </li><ul><li>Differ a system in functional modules that receive data and convert it to outputable data ( receive – edit – output ) </li></ul></ul></ul>
  57. 59. Object
  58. 60. Pipeline
  59. 61. Control styles <ul><li>Are concerned with the control flow between sub-systems. Distinct from the system decomposition model.
  60. 62. Centralised control </li><ul><li>One sub-system has overall responsibility for control and starts and stops other sub-systems. </li></ul></ul>
  61. 63. Control styles <ul><li>Event-based control </li><ul><li>Each sub-system can respond to externally generated events from other sub-systems or the system’s environment.
  62. 64. Broadcast model : </li><ul><li>Event is sent to every subsystem and this is programmed to handle these event </li></ul><li>Interrupt-driven model : </li><ul><li>Extern interrupts are handled by an interrupt handler and this handler send events to other components
  63. 65. Only used in Real-time-environments ( airbag in cars ) </li></ul></ul></ul>
  64. 66. Conclusion <ul><li>Architectural design is important (Root of complex software systems) </li><ul><li>Structure of your system
  65. 67. Dividing system into multiple subsystems
  66. 68. System analysis and stakeholder communication
  67. 69. Supports models for better re-usability
  68. 70. Supports models for different non-functional requirements </li></ul></ul>
  69. 71. Questions?

×