1 / 42

INF123 – Software Architecture

INF123 – Software Architecture. INF 123 – Software Architecture Thomas ( Debeauvais ) tdebeauv@uci.edu. Software Architecture. The set of most important design decisions “Most important” According to the stakeholders “Design decisions” Aware of the options Also called constraints

hilda
Télécharger la présentation

INF123 – Software Architecture

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. INF123 – Software Architecture INF 123 – Software Architecture Thomas (Debeauvais) tdebeauv@uci.edu

  2. Software Architecture • The set of most important design decisions • “Most important” • According to the stakeholders • “Design decisions” • Aware of the options • Also called constraints • More than just the code structure • Elegant

  3. Software architecture • Components • Connectors • Data • Style • If you follow the constraints • You’ll gain the benefits

  4. How • Basic tools: the MASC • Modularity • Abstraction • Separation of Concerns • More advanced tools • Object-oriented paradigm • Domain-specific architectures

  5. Non-functional requirements • Functional • “The system prints medical records” • Non-functional • “The system prints medical records quickly and confidentially.”

  6. Connectors • Allow components to transfer control and data with each other • Aka facilitating control flow and data flow What is control?

  7. Style: Main program and subroutines main Function calls Subroutine 1 Subroutine 2 Subroutine N … Subroutines: no side-effects, and not calling each other.

  8. Sequence diagram

  9. Distributed system • Components run concurrently • Components fail independently • No global clock • Latency Host 2 Component 3 Host 1 Host 3 Component 1 Component 4 Component 2 Component 5 Network interface of the OS

  10. OSI model: layers Web browser Web page Transparent! HTTP HTTP TCP TCP IP IP Physical link (copper wire, optic fiber, …)

  11. TCP vs UDP

  12. Constraints • Clients initiate the communication • Communication usually over the network • Server has the main functionality • No client-to-client communication • Fat vs thin clients

  13. Client-server: pros and cons • Pros • Computation and data collocated • Server = single authority, trusted • Ignore bad clients without affecting good clients • Cons • Server = single point of failure • Server can be a bottleneck

  14. Pipe and filter • Constraints: • Each task runs in its own process • Stream of data passed between tasks • Input/output formats • Gains: modularity, reuse, concurrency input simulation/ logic display

  15. Describing a Software Architecture • “Just look at the source code!” • Natural language • Easy to discuss and contract-like, but long to read • XML, JSON • Good for hierarchical structures, but hard to read • Images/screenshots • Good for usability arch, not for system or deploy • Box-and-arrow diagrams • Back and forth with XML/JSON

  16. Your own diagrams • Use the same symbol for the same things • Use standard symbols and representations • Don’t use the same symbol for different things • Add a legend if needed Client 1 Client 2 Send position Has a 2-way connection server

  17. p2p • Each peer is client and server to other peers • The topology can change • Pros • Scaling: each node provides CPU and storage • Robust if one node fails • Cons • Complex protocols for resource discovery • Security, trust management

  18. Napster Server = bottleneck Server = single point of failure Content Directory 2) Who has Gangnam Style? 3) A has Gangnam Style 1) I have Gangnam Style 4) Give me Gangnam Style Peer A Peer B 5) Here is Gangnam Style

  19. Flooding in Gnutella Broadcast to discover resources TTL flag limits flooding Seeds = reliable list to start

  20. Skype Privacy + Security: Hard to hack

  21. Sensor networks • Non-functional properties: • Low energy consumption • Fault-tolerance • Scalability

  22. Vanilla MVC

  23. Reactive MVC

  24. Web MVC

  25. Pubsub Eugster 2003: The many faces of publish/subscribe

  26. Event broker vs pubsub • Event broker = pubsub • With an intermediary • Where subscribers publish • And publishers subscribe • And usually with function callbacks rather than over the network • GUIs

  27. Dr. Eval eval(readline()), eval(message), …

  28. generated Sun RPC Hand-written Import function signature Import function signature interface.h caller.c callee.c Generate Call Call interface.x caller_stub.c callee_stub.c Generate Send XDR Recv XDR network

  29. XML RPC - request • POST /RPC2 HTTP/1.1 • User-Agent: Frontier/5.1.2 (WinNT) • Host: betty.userland.com • Content-Type: text/xml • Content-length: 181 • <?xmlversion="1.0"?> • <methodCall> • <methodName>examples.getStateName</methodName> • <params> • <param> • <value><int>41</int></value> • </param> • </params> • </methodCall> Verbose (SOAP!) bandwidth

  30. Remote Method Invocation Client Process Proxy Object B Proxy object is a hollow container of Method names. Remote Reference Module translates between local and remote object references. Object A Remote Reference Module Comm. Module Server Process Remote Reference Module Comm. Module Dispatcher sends the request to Skeleton Object Skeletondeserializes parameters, sends it to the object, & marshals the results for return Dispatcher Object B Skeleton for B’s Class MIDDLEWARE http://courses.engr.illinois.edu/cs425/fa2012/L8.fa12.ppt

  31. Service-oriented architecture Web Server Client (Browser) Web Server Web Server Business, Mashups Presentation Web Server

  32. Good: • Colorful • Bad: • - Yes goes down, then Yes goes right (be consistent)

  33. Good: • Transition labels are verbs (“Coin” should be “insert coin”) • States are participles (“locked”, “unlocked”) • Verb+ing is fine too! (e.g. “waiting for user input”) • States are circles • No end state: don’t need any in this case • Start state is obvious (nitpicking: convention is double circle)

  34. Good: • Server lifeline starts at the same time as the computer’s • The server lifeline is active only when the server works • Dotted arrow for the response • OK/meh: • sendUnsentEmail has no arrow back: what is happening on the server? Maybe it does not matter … • Bad: • “response” label for the response

  35. Metadata vs verbosity There are two kinds of pain. The sort of pain that makes you strong, or useless pain that is only suffering.

  36. SOAP vs REST • SOAP is verbose: large overhead of metadata and boilerplate text • SOAP • REST <?xml version="1.0"?> <soap:Envelopexmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:bodypb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserID>12345</pb:UserID> </pb:GetUserDetails> </soap:Body> </soap:Envelope> GET http://www.acme.com/phonebook/UserDetails/12345

  37. REST is made of several styles • Client-Server • Stateless • Cache • Layered • Code on demand • Uniform Interface • These styles are not always inter-compatible • But they are in the case of the WWW

  38. Proxy for load balancing: nginx

  39. Common security design decisions • Principle Of Least Authority – POLA • Separation of privilege • Complete mediation • Fail-safe defaults • Access control • …

  40. POLA Don’t touch it! Something shiny!

  41. Complete mediation • Make sure every access is permitted So easy … Frodo’s path Access control data Mordor checkpoints

  42. Impersonation Bob Alice Bob is reliable and everyone has a good opinion about Bob “I am Bob” Mallory (malicious)

More Related