Complexity COMP61511 (Fall 2017) Software Engineering Concepts in - PowerPoint PPT Presentation

Complexity COMP61511 (Fall 2017) Software Engineering Concepts in Practice Week 4 Bijan Parsia & Christos Kotselidis first.last@manchester.ac.uk (bug reports welcome!)

Complexity Challenge “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.” 2

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 Diagram source: McConell 6

Example: Components McConnell, 5.2: Figure 5-3. An example of a system with six subsystems 7

Example: Complexity via unconstrained communications McConnell, 5.2: Figure 5-4. An example of what happens with no restrictions on intersubsystem communications 8

Example: Low coupling is better McConnell, 5.2: Figure 5-5. With a few communication rules, you can simplify subsystem interactions significantly 9

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 com.oracle.graal.api.meta com.oracle.graal.api.code com.oracle.graal.graph com.oracle.graal.api.replacements com.oracle.graal.debug com.oracle.graal.sparc com.oracle.graal.hsail com.oracle.graal.options com.oracle.graal.nodes com.oracle.graal.replacements.verifier com.oracle.graal.ptx com.oracle.graal.amd64 com.oracle.graal.phases com.oracle.graal.alloc com.oracle.graal.truffle.printer com.oracle.graal.asm OKRA com.oracle.graal.word com.oracle.graal.bytecode com.oracle.graal.phases.common com.oracle.graal.api.runtime JUNIT com.oracle.max.cri com.oracle.truffle.api com.oracle.graal.asm.ptx com.oracle.graal.asm.hsail com.oracle.graal.lir com.oracle.graal.java com.oracle.graal.loop com.oracle.graal.virtual com.oracle.graal.service.processor com.oracle.graal.api.meta.test com.oracle.graal.api.test com.oracle.graal.graph.test com.oracle.graal.test com.oracle.max.base com.oracle.graal.debug.test com.oracle.truffle.api.test com.oracle.max.criutils com.oracle.truffle.api.dsl com.oracle.graal.asm.amd64 com.oracle.graal.lir.ptx com.oracle.graal.lir.hsail com.oracle.graal.asm.test com.oracle.graal.java.decompiler com.oracle.graal.compiler JDK_TOOLS com.oracle.max.asmdis com.oracle.max.asm com.oracle.truffle.api.dsl.test com.oracle.truffle.sl com.oracle.truffle.dsl.processor com.oracle.graal.lir.amd64 com.oracle.graal.asm.amd64.test com.oracle.graal.replacements com.oracle.graal.printer com.oracle.max.tools com.oracle.max.vm com.oracle.max.hcfdis com.oracle.truffle.sl.test com.oracle.graal.hotspot com.oracle.graal.replacements.amd64 com.oracle.graal.compiler.amd64 com.oracle.graal.java.decompiler.test com.oracle.graal.compiler.test com.oracle.max.tests.jsr292 com.oracle.max.vm.ext.bctrans com.oracle.max.c1x com.oracle.max.vm.ext.maxri com.oracle.graal.asm.sparc com.oracle.graal.compiler.ptx com.oracle.graal.hotspot.server com.oracle.graal.hotspot.amd64 com.oracle.graal.hotspot.amd64.test com.oracle.graal.replacements.test com.oracle.max.vm.ext.graal com.oracle.graal.nodes.test com.oracle.graal.compiler.sparc.test com.oracle.graal.hotspot.jdk8.test com.oracle.graal.jtt com.oracle.graal.compiler.amd64.test com.oracle.graal.truffle com.oracle.max.vm.ext.c1x TESTS_JASMIN_CLASSES com.oracle.max.vm.ext.t1x com.oracle.graal.lir.sparc com.oracle.graal.compiler.ptx.test com.oracle.graal.compiler.hsail com.oracle.graal.hotspot.test com.oracle.graal.truffle.test com.oracle.max.vm.ext.c1xgraal ASM com.oracle.max.tests com.oracle.max.vm.ext.jvmti com.oracle.max.vmdi com.oracle.max.elf com.oracle.graal.compiler.sparc com.oracle.graal.compiler.hsail.test.infra com.oracle.max.vm.tests com.oracle.max.vm.ext.vma com.oracle.max.jdwp com.oracle.max.tele.vm NB3_BUTTONS JLF_ICONS com.oracle.graal.hotspot.sparc com.oracle.graal.compiler.hsail.test com.oracle.max.vma.tools com.oracle.max.tele.jdwp com.oracle.max.tele.ins 13

Different Levels of Modularity JUNIT aal.api.test com.oracle.graal.graph.test com.oracle.graal.test com.oracle.max.base com.oracle.graal.debug.test JDK_TOOLS com.oracle.max.asmdis com.oracl com.oracle.max.tools com.oracle.max.vm com.oracle.max.tests.jsr292 com.oracle.max.vm.ext.bctrans co 14

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 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 • 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

System Software Direction of Design Architecture • 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 Software construction 17

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