Essential and accidental nature of SW modules Giuseppe

Essential and accidental nature of SW modules Giuseppe Valetto Drexel University - Dept. of Computer Science

Parnas’ insights o o o Modules = task assignments Proj. managers would like assignments to be as independent as possible SW Engineers can help by: n n o specify stable interfaces and use information hiding to make task assignments as independent as possible Bottom line: tasks that are “protected” by interfaces and largely independent

Underlying assumptions o There are some high-level activities Defining and assigning development tasks n Making them independent through design decisions n o o They incrementally feed on each other Once they converge, then other tasks can be spawned and development work can begin o Bottom line: design comes first and foremost n “design decisions … must be made before the work on independent modules can begin” [Parnas]

Essential difficulty of modularization o Modules are socio-technical abstractions n n n o Organizational and technical concerns take a life of their own n o Must satisfy proj. mgmt. concerns Must keep developers (and organizations) happy The above can be achieved only through highly technically involved means (design decisions) They are not likely to go hand in hand Bottom line: continuous tension can ensue n n n No silver bullet Insight into ways to balance disrupting forces Favor convergence and find equilibrium 4

Throw in a few accidental difficulties … 5

Language support o In programming languages, support for modules is very fine-grained n n o Often task size ~= package n o But packages do not have (a lot of) info hiding support APIs often seen as valuable info hiding barriers n o Information hiding operates at the level of classes Nobody really thinks about a single class as a task But granularity can be too coarse for partition tasks Hint: module systems are under development 6

Questions o Can we recognize module boundaries that are really effective for task protection? n n o Not all class interfaces are significant Some module boundaries span multiple How can we indicate, preserve and promote those interfaces? 7

Tasks happen … o Prevalent view of tasks as work items n o Work items are picked up as they occur n o bug reports, feature requests, etc. These tasks are NOT specified to remain independent from one another n n n o especially in very large-scale and “flat” projects If we are “lucky”, they will fall within info hiding boundaries Or they may straddle those boundaries Or concurrent tasks may occur within same boundaries Potential for cross-module, cross-team tasks is significant 8

Questions o o o Are there ways to “engineer” coherent tasks around incoming work items? What are the criteria to do that? Do you want to minimize tasks that are not protected by modules … n … or do you want to induce optimizations in the design using tasks as a lever? 9

Fluid design o Agile methodologies embrace change n n o Design emerges bottom-up from a sequence of developers’ decisions n n o e. g. continuous refactoring always question the status quo! As they are confronted with their assigned tasks And find ways to get out of each other’s way Modularization becomes “fluid” n n A means to the end, NOT the end Set of design decisions may be opportunistic, rather than strategic 10

Questions o o Is the fluidity of design conducive to effective modularization? How can we measure that effectiveness? What are the socio-technical effects of suboptimal modularization during this incremental process? What techniques can be used to alleviate those effects? 11

Accidental problems Tasks happen, are not planned or engineered 2. Information hiding for modules and task granularity do not match well Ergo … 3. Design decisions become fluid 1. 12

Moving towards answers … 13

Recognizing good emergent design o The creed of agile methods: n n o How can we figure whether it happens? n n n o Emergent design decisions will converge in the long term towards stable, high value modularization Which will provide adequate protections to most tasks Perhaps you get “luckier” with time: more and more tasks fall neatly within modularization boundaries Perhaps use statistics for tasks that straddle module boundaries to (re-)evaluate those design decisions As well as statistics for tasks that remain well encapsulated Incrementally recognize “good” interfaces and include them into API with proper granularity 14

Task engineering o Example: agile methodologies have a concept of iterations n n o Containing a selected set of “user stories” Developers choose user stories they want to work on Iterations might form a trajectory in between stable states of design n Within an iteration, design decisions are fair game and design is totally fluid At the end of iteration there is an emergent modularization Which serves for deciding how to structure and assign tasks in the next one 15

Organizational perspective o V&V for this incremental design process comes from the software team n o o Measure the ability of team to live and operate efficiently with the modularization boundaries Single out where it does not work n n o some amount of collaboration will always be needed It may not be because a design flaw But because that specific design decision does not serve the coordination needs of the team This way the nature of the organization can drive the design towards a “comfortable” modularization 16

Research directions o How to foster a “good” emergent design for task protection n o Does it help to try to actively “engineer” tasks, as opposed to pick up work items? n o And how to engineer them How to guide design options from an organizational perspective n o And how to measure it And how to decide which are conducive to collaboration When can fostering emergent teams help n And how to favor them 17