w3-complexity and design copy - University of Manchester
22
Complexity COMP61511 (Fall 2017) Software Engineering Concepts in Practice Week 4 Bijan Parsia & Christos Kotselidis [email protected] (bug reports welcome!)
Transcript of w3-complexity and design copy - University of Manchester
Complexity
COMP61511 (Fall 2017) Software Engineering Concepts
in Practice
Week 4 Bijan Parsia & Christos Kotselidis
[email protected] (bug reports welcome!)
Complexity Challenge
2
“But when projects do fail for reasons that are primarily technical, the reason is often uncontrolled complexity....
When a project reaches the point at which no one completely understands the impact that code changes in one area will have on other areas, progress grinds to a halt.”
Complexity Challenge
• “Software's Primary Technical Imperative has to be managing complexity.” • McConnell, 5.2
• Architecture is key to managing complexity • Architecture provides a guide • Good architecture controls interaction
• which allows considering subsystems independently
3
Dealing with complexity
• We can’t comprehend the entire system in detail, so we use information hiding via • Modularisation • Abstraction
• …to be able to effectively deal with complexity
4
Modularity and abstraction are major aids to understanding
• Using modularisation and abstraction, we have the intellectual leverage to understand and (informally) reason about systems
• We can apply these concepts at different levels to aid our understanding of a system
• In turn understanding enables us to • Go about constructing systems • Maintain them • Extend them
5
Levels of Design• Modularity
• Confines the details • So they don’t matter “from
outside”
• Facilitates abstraction
• As we move up levels • We lose detail, and • Expand scope of what we can
understand • Good design and
construction means that the details can be safely ignored at higher levels
6Diagram source: McConell
Example: Components
7
McConnell, 5.2: Figure 5-3. An example of a system with six subsystems
Example: Complexity via unconstrained communications
8
McConnell, 5.2: Figure 5-4. An example of what happens with no restrictions on intersubsystem communications
Example: Low coupling is better
9
McConnell, 5.2: Figure 5-5. With a few communication rules, you can simplify subsystem interactions significantly
Different Levels of Modularity
• Notice modularity, encapsulation and interfaces at different levels • Subsystem • Package • Object
10
Different Levels of Modularity
11
Different Levels of Modularity
• LOC: 891K (Java, C, Python, Assembly, Make etc.)
• Files: 3957
• Classes: 9788
• Packages: ~100 packages
• Projects: ~30
12
Different Levels of Modularity
13
com.oracle.graal.asm.amd64.test
com.oracle.graal.asm.testcom.oracle.graal.asm.amd64
com.oracle.graal.asm
com.oracle.graal.test
com.oracle.graal.api.runtime
com.oracle.graal.amd64
com.oracle.max.vm.ext.maxri
com.oracle.max.vm com.oracle.max.hcfdis
com.oracle.max.base
JDK_TOOLS com.oracle.max.asm
com.oracle.max.criutils
com.oracle.max.asmdis
com.oracle.graal.hotspot
com.oracle.graal.replacements com.oracle.graal.printer
com.oracle.graal.word
com.oracle.graal.compiler
com.oracle.graal.java
com.oracle.graal.java.decompiler
com.oracle.graal.compiler.ptx
com.oracle.graal.lir.ptx
com.oracle.graal.lircom.oracle.graal.asm.ptx
com.oracle.max.vm.ext.c1x
com.oracle.max.c1x
com.oracle.graal.compiler.hsail
com.oracle.graal.lir.hsail
com.oracle.graal.hotspot.amd64
com.oracle.graal.asm.hsail
com.oracle.graal.compiler.amd64com.oracle.graal.replacements.amd64
com.oracle.graal.nodes
com.oracle.graal.api.code com.oracle.graal.graph com.oracle.graal.debugcom.oracle.graal.api.replacements
com.oracle.graal.jtt
com.oracle.graal.compiler.test
com.oracle.truffle.api.dsl.test
com.oracle.truffle.api.dsl
JUNIT com.oracle.truffle.api
com.oracle.graal.truffle.test
com.oracle.graal.truffle
com.oracle.graal.truffle.printer
com.oracle.graal.sparc
com.oracle.graal.api.meta
com.oracle.max.vm.ext.vma
com.oracle.max.vm.ext.jvmti
com.oracle.max.vm.ext.graal com.oracle.max.vm.ext.t1x
com.oracle.graal.compiler.hsail.test
com.oracle.graal.compiler.hsail.test.infra
com.oracle.graal.phases
com.oracle.graal.options
com.oracle.graal.java.decompiler.test
com.oracle.max.vm.tests
com.oracle.max.testsASM
TESTS_JASMIN_CLASSEScom.oracle.graal.compiler.amd64.test
com.oracle.graal.hsail
OKRA
com.oracle.graal.hotspot.test
com.oracle.graal.replacements.test
com.oracle.max.tests.jsr292
com.oracle.graal.phases.common
com.oracle.graal.lir.amd64
com.oracle.max.vm.ext.c1xgraal
com.oracle.graal.api.meta.test
com.oracle.max.tools
com.oracle.graal.nodes.test
com.oracle.graal.alloc
com.oracle.graal.virtualcom.oracle.graal.loop
com.oracle.truffle.dsl.processor
com.oracle.graal.replacements.verifier
com.oracle.max.vm.ext.bctrans
com.oracle.max.jdwp
com.oracle.max.vmdi
com.oracle.max.tele.ins
com.oracle.max.tele.vm JLF_ICONSNB3_BUTTONS
com.oracle.max.elf
com.oracle.graal.hotspot.sparc
com.oracle.graal.compiler.sparc
com.oracle.graal.lir.sparc
com.oracle.graal.bytecode
com.oracle.graal.compiler.ptx.test
com.oracle.graal.ptx
com.oracle.max.tele.jdwp
com.oracle.graal.asm.sparc
com.oracle.max.vma.tools
com.oracle.graal.service.processor com.oracle.truffle.api.test
com.oracle.graal.compiler.sparc.test
com.oracle.graal.graph.test
com.oracle.truffle.sl.test
com.oracle.truffle.sl
com.oracle.max.cri
com.oracle.graal.hotspot.amd64.testcom.oracle.graal.hotspot.server
com.oracle.graal.debug.testcom.oracle.graal.api.test
com.oracle.graal.hotspot.jdk8.test
Different Levels of Modularity
14
com.oracle.graal.asm.amd64.test
com.oracle.graal.asm.testcom.oracle.graal.asm.amd64
com.oracle.graal.asm
com.oracle.graal.test
com.oracle.graal.api.runtime
com.oracle.graal.amd64
com.oracle.max.vm.ext.maxri
com.oracle.max.vm com.oracle.max.hcfdis
com.oracle.max.base
JDK_TOOLS com.oracle.max.asm
com.oracle.max.criutils
com.oracle.max.asmdis
com.oracle.graal.hotspot
com.oracle.graal.replacements com.oracle.graal.printer
com.oracle.graal.word
com.oracle.graal.compiler
com.oracle.graal.java
com.oracle.graal.java.decompiler
com.oracle.graal.compiler.ptx
com.oracle.graal.lir.ptx
com.oracle.graal.lircom.oracle.graal.asm.ptx
com.oracle.max.vm.ext.c1x
com.oracle.max.c1x
com.oracle.graal.compiler.hsail
com.oracle.graal.lir.hsail
com.oracle.graal.hotspot.amd64
com.oracle.graal.asm.hsail
com.oracle.graal.compiler.amd64com.oracle.graal.replacements.amd64
com.oracle.graal.nodes
com.oracle.graal.api.code com.oracle.graal.graph com.oracle.graal.debugcom.oracle.graal.api.replacements
com.oracle.graal.jtt
com.oracle.graal.compiler.test
com.oracle.truffle.api.dsl.test
com.oracle.truffle.api.dsl
JUNIT com.oracle.truffle.api
com.oracle.graal.truffle.test
com.oracle.graal.truffle
com.oracle.graal.truffle.printer
com.oracle.graal.sparc
com.oracle.graal.api.meta
com.oracle.max.vm.ext.vma
com.oracle.max.vm.ext.jvmti
com.oracle.max.vm.ext.graal com.oracle.max.vm.ext.t1x
com.oracle.graal.compiler.hsail.test
com.oracle.graal.compiler.hsail.test.infra
com.oracle.graal.phases
com.oracle.graal.options
com.oracle.graal.java.decompiler.test
com.oracle.max.vm.tests
com.oracle.max.testsASM
TESTS_JASMIN_CLASSEScom.oracle.graal.compiler.amd64.test
com.oracle.graal.hsail
OKRA
com.oracle.graal.hotspot.test
com.oracle.graal.replacements.test
com.oracle.max.tests.jsr292
com.oracle.graal.phases.common
com.oracle.graal.lir.amd64
com.oracle.max.vm.ext.c1xgraal
com.oracle.graal.api.meta.test
com.oracle.max.tools
com.oracle.graal.nodes.test
com.oracle.graal.alloc
com.oracle.graal.virtualcom.oracle.graal.loop
com.oracle.truffle.dsl.processor
com.oracle.graal.replacements.verifier
com.oracle.max.vm.ext.bctrans
com.oracle.max.jdwp
com.oracle.max.vmdi
com.oracle.max.tele.ins
com.oracle.max.tele.vm JLF_ICONSNB3_BUTTONS
com.oracle.max.elf
com.oracle.graal.hotspot.sparc
com.oracle.graal.compiler.sparc
com.oracle.graal.lir.sparc
com.oracle.graal.bytecode
com.oracle.graal.compiler.ptx.test
com.oracle.graal.ptx
com.oracle.max.tele.jdwp
com.oracle.graal.asm.sparc
com.oracle.max.vma.tools
com.oracle.graal.service.processor com.oracle.truffle.api.test
com.oracle.graal.compiler.sparc.test
com.oracle.graal.graph.test
com.oracle.truffle.sl.test
com.oracle.truffle.sl
com.oracle.max.cri
com.oracle.graal.hotspot.amd64.testcom.oracle.graal.hotspot.server
com.oracle.graal.debug.testcom.oracle.graal.api.test
com.oracle.graal.hotspot.jdk8.test
The activity of design and when we do it
• Design is an activity in many fields • e.g.: Architecture (for buildings), computer
architecture to code and test construction
• Characteristics of software design • Knowledge in three kinds of domain:
Application, technical domain and design domains • Requires motivated choices and tradeoffs • Knows what to take account of, and
what to ignore • Multi-faceted and sometimes multi-level
15
Design is a Wicked Problem
• Change is a reality • Requirements and problem definitions change
• Exogenously | the external world changes • e.g. a regulation is passed during development
• Endogenously | triggered by the evolving system • e.g. people learn that they misunderstood the problem
• Software development must cope • Methodologically | e.g. agile methods respond well to change • Architecturally | e.g. modularity lets us replace modules • Constructionally| e.g. robust test suites support change
16
Horst Rittel and Melvin Webber defined a "wicked" problem as one that could be clearly defined only by solving it, or by solving part of it (1973). McConnell, 5.1
Direction of Design
• Top down • Start with the general problem • Break it into manageable parts
• Each part becomes a new problem • Decompose further • Bottom out with concrete code
• Bottom up • Start with a specific capability
• Implement it • Repeat until confident enough
• to think about higher level pieces
17
System Software Architecture
Software construction
Opportunistic focus
• Top down and bottom up aren’t exclusive • “Thinking from the top”
• Focuses our attention on the whole system • “Thinking from the bottom”
• Focuses our attention on concrete issues • Being able to choose where you focus your attention
opportunistically is a great help • For example working at the top level, you may wonder
will this really work, so you consider realisation at a lower level of detail • Will have to rework the top level if it doesn’t work at a
greater level of detail
18
Exploring the Design Space
• Wickedness suggests • we need to do stuff early • build experimental solutions
• Three common forms • Spikes • Prototypes • Walking skeletons
19
Spikes
• Very small program to explore an issue • Scope of the problem is small
• Often intended to determine specific risk • Is this technology workable?
• No expectation of keeping
20
Prototype
• Can have some small or large scope
• Intended to demonstrate something, rather than ‘just’ find out about technology (a spike)
• Mock ups through working code
• Can be “on paper”!
• Prototypes get thrown away • Or are intended to!
21
Walking Skeleton
• Small version of “complete” system • “tiny implementation of the system that performs
a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.” - Alistair Cockburn
• Walking skeletons are meant to evolve into the software system
• Consider miniwc.py!22
