Super-Design Informatics 122 Alex Baker

System Design Arch. Imp. Design Code In this class we’ve gone…

Recapping 121 System design  describes what the software system should do “How do we fundamentally approach the problem?” “What is desirable?”  Architecture, and… Implementation design  describes what the implementer should do “How do we make the approach reality?” “What is a feasible answer?”  Class diagrams, and…

Recapping 121 A system design captures the essence of the solution An implementation design captures the full solution

System Design Arch. Imp. Design Code Putting it back in perspective

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

“Big” Projects What’s the biggest project you’ve worked on?

“Big” Projects What’s the biggest project you’ve worked on? A glimpse of the real world 3 particularly interesting issues

1) Planning for Change? So we know we want to do it, but what does it mean?

1) Planning for Change? So we know we want to do it, but what does it mean? What is the role of change, in theory, in:  Waterfall lifecycle model  Iterative approaches  Agile approaches

The Waterfall Model System design sets up implementation design  Provides conceptual guidance  Specifies parameters  Suggests structure  Suggests modules and work divisions

The Waterfall Model System design sets up implementation design  Provides conceptual guidance  Specifies parameters  Suggests structure  Suggests modules and work divisions Never to return! (In theory)

A linear process? (Really?) Goal System Design Implementation Design Code

An iterative process - Completely? New designs, based on results from previous iterations – no actual reuse?

The agile process? Reworking, refactoring

The agile process? Reworking, refactoring

In reality, not so simple Debugging Adjusting Expanding Refactoring Redesigning Re-architecting Reconceiving

Why do we change? DesirableFeasible

In theory: DesirableFeasible System design

In theory: DesirableFeasible System design Implementation design

In theory: DesirableFeasible System design Implementation design Implementations

On the other hand DesirableFeasible System design Implementation design Implementations

On the other hand Some degree of learning and changing How can we apply what we are learning most easily? DesirableFeasible

Software processes No process is truly linear or iterative We don’t get it right the first time Code, designs, architectures, concepts are often reused when we start over Many kinds of changes  Many ways to design for change

Consider VBoard What changes would we like to make?

VBoard: Expanding Along existing axis…  Adding more UI widgets  Implementing new gestures Fairly easy? We know how to design for these changes

VBoard: Bugs Sometimes relationship lines “fall under”:  Can we understand the program flow to know why?  Can we find the place in the code that causes this problem?  Can it be fixed with minimal rippling?

Problems: Recoding or Redesigning? Suppose our (future) gesture system is clunky:  Have we reused this? Can it be fixed? The program grinds to a halt eventually!  Is this a bug or a fundamental design flaw?

VBoard: Reconceiving? For example:  Making it UML-specific  Is the grid the right approach to organization?  Should we have scraps?

VBoard: Reconceiving? For example:  Making it UML-specific  Is the grid the right approach to organization?  Should we have scraps? How much redesign to we have to do?  Do we start over?  What knowledge can we apply?

When design is more than UML Large-scale Long-term Existing systems and frameworks These challenges are greater

Changes Large-scale Long-term Existing systems and frameworks

Changes: Large Scale Design More people working  More people changing  People working with more changes they didn’t make  Code level changes become design changes..  Does a design accommodate this? More places to change  Harder to fix, harder to contain Design might need to be divided among several

Changes: Long-term Design Large-scale Long-term Existing systems and frameworks (!)2007

Changes: Long-term Design Needs more likely to change over time  Understanding changes  Standards change  Platforms change  Market pressures for more features  Customer changes More problematic to make changes  Developers change, assumptions lost

Changes Large-scale Long-term Existing systems and frameworks

Changes: Existing Materials Can be harder to change  May be harder to understand  May not have full access to source, etc.  May not understand what you do have  May not be allowed to change

Changes: “Real” projects What can we do? No single answer, but:  Learning before the real thing  Rigor and wisdom in design  Well-reasoned adjustments  Reuse, patterns, styles, frameworks  Awareness of these issues  Practice (hint, hint)

Tired of talking about designing for change?

2) Unified Design Vision

2) Unified Design Vision: Tough! Adding patterns assignment Also a problem in “Cake” Design drift, design decay

Choices have subtle effects Modeless interaction in VBoard  What if you didn’t know? Having a word class in Scrabble The piece models in Jetris

Choices have subtle effects Modeless interaction in VBoard  What if you didn’t know? Having a word class in Scrabble The piece models in Jetris Is everyone on board?

When design is more than UML Again… Large-scale Long-term Existing systems and frameworks

Consistency: Large Scale Lots of design work, lots of people needed Maintaining shared goals and knowledge Possible solutions  Product Lines  Frameworks/Patterns/Architectural Styles  Guidelines/Principles  Brooks’ Surgical Team

Consistency: Long Term Designer turnover / legacy systems Design Drift Design Decay

Consistency: Existing Frameworks In reality, a lot is reuse  Frameworks (Piccolo)  Libraries  Components Must conform  Consider Piccolo  Or Jetris Brooks’ Conformity  Adhering to the real world one of software’s issues

Consistency of Vision Want a single, unified vision But this is tough with:  Tons of people  Changing people and changing needs  Pressures to conform to existing models Tough enough on a personal project

Consistency of Vision Has helped inspire:  Software Architecture  Architectural Style  Product Line Architectures  Design Patterns  Traceability  Rationale

3) Representations One or Many?

Architecture (Buildings)

Process Design

Multiple Representations Translating between them Easier in some fields than others May require  Language translation  Additional design decisions Waterfall model

Single Representation Using the same for multiple purposes  Likely to be subpar for one or the other Agile’s approach, code for everything  Recording decisions  Communication  Reflective conversing

When design is more than UML One more time  Large-scale  Long-term  Existing systems and frameworks

Representations: Large Scale Multiple  Complexity (translation) gets worse  Takes longer to get to coding, will more change? Single - Code becomes especially tough  Can the implementers keep their bearings?  Is a unified vision feasible?  Can you find the rationale you need?

Representations: Long Term Multiple - Consistency and traceability of changes Single - New hire issues

Representations: Existing Frameworks Single (same as framework)  Can constrain your only mode of working (!) Multiple  Need to avoid misrepresenting the framework’s needs across documents

Representations No one solution There’s a lot of complexity, it all has to go somewhere “No silver bullet” as they say.. Software’s a hassle!

Unique Requirements Banks Satellites Telephone Networks Car Driving Software

Unique Reqs - Bank Software Verifiable Long term  Run for decade+  Laws change  Finance packages change

Unique Reqs - Satellites Software must be reliable  Can it be proven  Can we fix it remotely? Long term  High cost of building and installing Highly interconnected System Design  UML not the answer

Unique Reqs – Telephone Network Reliability Distribution Fault tolerance  How do we accommodate outages  Will losing one node cripple the system? Different representations needed

Unique Reqs – Car Driving SW Complexity Reliability Can we count on input from sensors? What happens when there’s an error?

Unique Reqs – Car Driving SW Reliability Can we count on input from sensors? What happens when there’s an error? UML far from enough

Wrapup Designing for change Multiple designer issues Representation issues

There’s more to software design than we can show you first hand UML often not enough, need “meta-design” Senior project’s a start

Remember: Talks Tuesday Questions about assignment? About Informatics?