+ Informatics 122 Software Design II Lecture 13 Emily Navarro Duplication of course material for any commercial purpose without the explicit written permission of the professor is prohibited. 1

+ Today’s Lecture Design in the Large 2

+ Focus of 122 [Application design] [Interaction design] [Architecture design] Implementation design Maintenance design 3

+ Application, Interaction, Architecture Design Describe what the software system should do “How do we fundamentally approach the problem?” “What is desirable?” Identifying stakeholders and goals Defining how your system will meet these goals at a high level Creative thinking, incomplete specifications 4

+ Purpose of Implementation Design An implementation design is a road map An implementation design describes a path from application / interaction / architecture design to the product An implementation design describes what the implementers should do An implementation design is a guide towards future change 5

+ Maintenance Design Design Recovery How do we understand the design as it exists in the code and documentation? Design Patterns How can we improve simple aspects of the existing design with known “solutions” Reuse How can we leverage what is “out there” in our design? 6

+ The “Big Picture” In the sense of: 1. New perspective on some major topics 2. The impact of these issues on “big” projects 7

+ Two Key Issues in Design-in-the- Large Unified Design Vision Representations 8

+ Unified Design Vision 9

+ Unified Design Vision: Tough! How easy was it to understand SimSE? How did you attempt a unified design vision among your group? How was a lack of a unified design vision evident in your group? 10

+ Unified Design Vision Design is more than UML I hope it’s been obvious from the first assignment However, it does help… In reality, a lot is using conventions, standards, etc. The way we design “here” And lots of interaction, coordination, and communication And lots of reuse Frameworks Libraries Components 11

+ Unified Design Vision New challenges, however, make it more difficult Very large scale systems Long lived systems Global software development 12

+ Very Large Scale Systems Systems of systems Examples: defense systems, financial trading, healthcare, government systems, energy distribution Traditional approaches to software engineering are no longer adequate How can we reduce the complexity of the unified vision? Architectural styles The cornerstone of the vision is something we all know works and is simple Architecture description languages To provide higher level views Component-based design, service-oriented architectures To partition the system and set boundaries We can also reuse large scale design and architecture 13

+ Long-lived Systems How can we guarantee our vision stands the test of time? Process enforcement and the IDE Tracking issues, lots of reviews, automated code analysis, emergent design, etc. How can we deal with turnover? More documentation, better documentation? Training is key! 14

+ Global Software Development How can we guarantee the vision is shared by different groups? How does communication and coordination occur in distributed environments? GSD is a hot topic for research and a challenge in the real world Supporting with processes and tools Improving awareness in IDEs 15

+ Representations How do we represent our system? One or many views? One or many notations? What do they abstract? / What do they emphasize? 16

+ Architecture (Buildings) 17

+ Single Representation Using one single representation of the system serves all purposes shared by everyone But how can we guarantee interpretations are the same? No chance for inconsistency Agile approach: code is design Recording decisions Communication Does it scale? 18

+ Multiple Views Some facts… “The code is the truth but not the whole truth” [Booch] UML is only good for “low-level design” Traditional architecture diagrams (boxes and arrows) focus only on high-level functionality 19

+ Multiple Views One possible answer Views [Philippe Kruchten] 20

+ Multiple Views Still leaves many questions What level of abstraction is right? Takes longer to get to coding; will more change? How do we maintain them over time? There are many challenges Translating between different views Keeping consistency between different levels of abstraction Guaranteeing they are usable May require Language translation Additional design decisions Lots and lots of consistency checking! 21

+ More Approaches to Supporting Design-in-the-Large Design rationale Architectural styles Enterprise frameworks Product lines 22

+ Design Rationale Listing of decisions made during a design process, along with reasons why they were made other alternatives considered tradeoffs that were evaluated any other relevant information Purpose: to keep a record of this knowledge and communicate it to others Tools exist for managing design rationale In software engineering as well as other disciplines 23

+ Architectural Styles Provide “a vocabulary of components and connectors, with constraints on how they can be defined [Shaw, Garlan]” a common language with which to describe classes of systems Peer-to-peer Pipe and filter Client-server C2 REST … 24

+ Enterprise Frameworks 25

+ Software Product Lines Can we use lessons from mass production of physical goods in software? How can we produce software with minimum (human) effort? 26

+ Wrapping Up Maintaining a unified vision of design requires lots of support! Multiple views will be necessary (unless you’re “agile”) 27

+ Bottom Line There’s more to software design than we can show you firsthand Senior project’s a start Once you get “out there” you’ll see it more clearly 28

+ Next Time Reuse Presentations 29