1. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 1 Informatics 121 Software Design I Lecture 13 Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited.

2. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 2 Discussion There will be discussion this Friday

3. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 3 Today’s lecture Design methods (architecture design)

4. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 4 Intermezzo Experts focus on the essence Experts address knowledge deficiencies Experts go as deep as needed Experts try the opposite Experts do something (else)

5. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 5 Application design Interaction design Architecture design Implementation design Analysis competitive testing contextual inquiry feature comparison stakeholder analysis task analysis critical incident technique interaction logging personas scenarios framework assessment model-driven engineering quality-function- deployment reverse engineering world modeling release planning summarization test-driven design visualization Synthesis affinity diagramming concept mapping mind mapping morphological chart design/making participatory design prototyping storyboarding architectural styles architectural tactics component reuse decomposition pair programming refactoring search software patterns Evaluation requirements review role playing wizard of oz cognitive walkthrough evaluative research heuristic evaluation think-aloud protocol formal verification simulation weighted objectives correctness proofs inspections/reviews parallel deployment testing Software design methods

6. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 6 Framework assessment Framework assessment is the process of finding, comparing, and selecting an infrastructure upon which to build the system

7. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 7 Procedure Identify desired characteristics Identify potential frameworks Assess potential frameworks

8. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 8 Example: identify desired characteristics General – scalability – security – easy of use – performance Programming model – model-view-controller – push-based / pull-based – three-tier Application specific – programming language – data replication & synchronization – transaction support – form-based input External factors – programmers’ expertise – license – cost

9. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 9 Example: identify potential frameworks Struts Django Ruby on Rails Symfony Spring Jboss Node.js Angular.js … Oracle ADF Swing JMS TIBCO Processing …

10. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 10 Example: assess potential frameworks

11. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 11 Typical notation: table

12. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 12 Typical notation: graph

13. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 13 Criteria for successful use Must have a clear understanding of the architectural goals of the system Must be able to precisely assess the criteria Must select the right comparison criteria

14. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 14 Strengths and weaknesses Strengths Forces the detailed articulation of architectural goals Might identify new, unexpected opportunities Can lead to significant savings in cost and effort Weaknesses Is often difficult to precisely understand the long-term impact of choosing a given framework Might well require getting hands- on experience in using some frameworks for some time Does not work well for legacy code

15. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 15 Application design Interaction design Architecture design Implementation design Analysis competitive testing contextual inquiry feature comparison stakeholder analysis task analysis critical incident technique interaction logging personas scenarios framework assessment model-driven engineering quality-function- deployment reverse engineering world modeling release planning summarization test-driven design visualization Synthesis affinity diagramming concept mapping mind mapping morphological chart design/making participatory design prototyping storyboarding architectural styles architectural tactics component reuse decomposition pair programming refactoring search software patterns Evaluation requirements review role playing wizard of oz cognitive walkthrough evaluative research heuristic evaluation think-aloud protocol formal verification simulation weighted objectives correctness proofs inspections/reviews parallel deployment testing Software design methods

16. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 16 Reverse engineering Reverse engineering is the process of extracting existing design knowledge from a code base

17. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 17 Procedure Determine what design knowledge you need to obtain, and why Decide upon strategy Execute Verify

18. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 18 Example: determine what design knowledge… What: architecture of HADOOP Why: to consider possible refactoring What: data anonymization in the Google AdSense pipeline Why: make adjustments because of changes in privacy laws

19. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 19 Example: decide upon strategy Look for existing documentation Read code and make diagrams Talk to other developers Use tools

20. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 20 Example: execute

21. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 21 Example: verify Bash “ground truth” ACDC ZBRBunch

22. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 22 Typical notation: diagram

23. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 23 Criteria for successful use Should have access to as much information as possible Should look for focused, localized knowledge Must iterate

24. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 24 Strengths and weaknesses Strengths Reveals the actual (often messy) implementation structures of the current system Can help re-orient the team if the new knowledge is shared Weaknesses Just like the original design documentation, the new knowledge can be lost Typically can only recover the results from making design decisions, not necessarily the decisions or deliberations behind them (the rationale) Can be very labor intensive Results may be inaccurate

25. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 25 Application design Interaction design Architecture design Implementation design Analysis competitive testing contextual inquiry feature comparison stakeholder analysis task analysis critical incident technique interaction logging personas scenarios framework assessment model-driven engineering quality-function- deployment reverse engineering world modeling release planning summarization test-driven design visualization Synthesis affinity diagramming concept mapping mind mapping morphological chart design/making participatory design prototyping storyboarding architectural styles architectural tactics component reuse decomposition pair programming refactoring search software patterns Evaluation requirements review role playing wizard of oz cognitive walkthrough evaluative research heuristic evaluation think-aloud protocol formal verification simulation weighted objectives correctness proofs inspections/reviews parallel deployment testing Software design methods

26. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 26 Architectural styles Architectural styles is the process of basing the architectural design on choice of a pre-existing, named collection of design decisions

27. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 27 Procedure Classify the type/domain of application Identify potential architectural styles Match style(s) to type/domain Examine imposed constraints

28. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 28 Example: classify the type/domain of application Business processing Web application Game Robotics Social media Flight simulation …

29. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 29 Example: identify potential architectural styles Traditional, language influenced – main program and subroutines – object-oriented Layered – virtual machine – client-server Data flow – batch sequential – pipe and filter Shared memory – blackboard – rule-based Interpreter – interpreter – mobile code Implicit invocation – event-based – publish-subscribe Peer-to-peer Domain-specific – three-tier – sense-compute-control – representational state transfer

30. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 30 Example: match style(s) to type/domain Data flow (or batch sequential) to business processing Representational state transfer to web applications Publish subscribe to internet notification systems Sense-compute-control to robotic systems … Often, a mix of styles is necessary

31. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 31 Example: examine imposed constraints Client-server does not allow the server on its own to send messages to the clients Representational state transfer does not allow the server to keep state Publish-subscribe does not allow direct invocation

32. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 32 Typical notation: diagram

33. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 33 Typical notation: set of principles Client-server Stateless Cache Uniform interface Layered system Code on demand

34. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 34 Criteria for successful use Must have a clear understanding of the architectural goals of the system Should understand how other, similar systems are built Must understand the specific needs of the application, and carefully examine the imposed constraints in the context of these needs

35. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 35 Strengths and weaknesses Strengths Architectural styles are ‘tried and true’ in encoding long-term, beneficial experiences Help constrain the remainder of the design problem Help create a shared vocabulary and understanding Can save significant effort Weaknesses Frequently, existing styles must be tweaked to the problem at hand Many styles only provide very high-level guidance Does not work well for legacy code

36. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 36 Application design Interaction design Architecture design Implementation design Analysis competitive testing contextual inquiry feature comparison stakeholder analysis task analysis critical incident technique interaction logging personas scenarios framework assessment model-driven engineering quality-function- deployment reverse engineering world modeling release planning summarization test-driven design visualization Synthesis affinity diagramming concept mapping mind mapping morphological chart design/making participatory design prototyping storyboarding architectural styles architectural tactics component reuse decomposition pair programming refactoring search software patterns Evaluation requirements review role playing wizard of oz cognitive walkthrough evaluative research heuristic evaluation think-aloud protocol formal verification simulation weighted objectives correctness proofs inspections/reviews parallel deployment testing Software design methods

37. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 37 Decomposition Decomposition is the process of breaking a larger problem into smaller, independently addressable parts

38. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 38 Procedure Determine criteria by which to decompose the problem Determine the parts by applying the criteria Identify the interfaces through which the parts interact

39. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 39 Example: determine criteria by which to… Information hiding Separation of concerns Anticipation of change Incrementality Reusability Generality

40. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 40 Example: determine the parts by applying the… Consider all of the functionality that must be addressed Suggest components and make diagrams Work with other developers Use tools

41. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 41 Example: determine the parts by applying the…

42. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 42 Example: determine the parts by applying the…

43. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 43 Example: identify the interfaces… Hypertext Transfer Protocol (HTTP) – GET – HEAD – POST – PUT – DELETE – TRACE – OPTIONS – CONNECT – PATCH

44. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 44 Example: identify the interfaces… http://httpd.apache.org/docs/2.4/mod/ http://httpd.apache.org/docs/2.4/mod/directives.html http://httpd.apache.org/docs/2.4/mod/core.html http://httpd.apache.org/docs/2.2/developer/hooks.html

45. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 45 Typical notation: diagram

46. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 46 Typical notation: API specification void debug( java.lang.CharSequence ) Send a message to the user in the debug error level. void debug( java.lang.CharSequence, java.lang.Throwable ) Send a message (and accompanying exception) to the user in the debug error level. The error's stacktrace will be output when this error level is enabled. void debug( java.lang.Throwable ) Send an exception to the user in the debug error level. The stack trace for this exception will be output when this error level is enabled. void info( java.lang.CharSequence ) Send a message to the user in the info error level. void info( java.lang.CharSequence, java.lang.Throwable ) Send a message (and accompanying exception) to the user in the info error level. The error's stacktrace will be output when this error level is enabled. void info( java.lang.CharSequence ) Send an exception to the user in the info error level. The stack trace for this exception will be output when this error level is enabled. …

47. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 47 Criteria for successful use Should fully or near-fully understand the functionality that must be provided Must identify and apply proper criteria Should think deeply Must iterate

48. Department of Informatics, UC Irvine SDCL Collaboration Laboratory Software Design and sdcl.ics.uci.edu 48 Strengths and weaknesses Strengths Is the fundamental design method in software engineering that applies in numerous situations Is the only way to address large- scale problems Helps increase the ability to develop the software in parallel Necessary precision frequently leads to the need to clarify other aspects of the design Weaknesses Often degenerates into unprincipled discussion Certain concerns remain crosscutting, meaning that an ‘ideal’ decomposition cannot be attained Can be very labor intensive Can remain subjective