Editing Computer program (section)

==Software engineering and computer programming==
[[File:Two women operating ENIAC (full resolution).jpg|thumb|right|Prior to programming languages, [[Jean Bartik|Betty Jennings]] and [[Fran Bilas]] programmed the [[ENIAC]] by moving cables and setting switches.]]

[[Software engineering]] is a variety of techniques to produce [[software quality|quality]] ''computer programs''.<ref name="se-preface1">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = Preface
  | isbn = 0-256-08515-3
}}</ref> [[Computer programming]] is the process of writing or editing [[source code]]. In a formal environment, a [[systems analyst]] will gather information from managers about all the organization's processes to automate. This professional then prepares a [[Functional requirement|detailed plan]] for the new or modified system.<ref name="pis-ch12-p507">{{cite book
  | last = Stair
  | first = Ralph M.
  | title = Principles of Information Systems, Sixth Edition
  | publisher = Thomson
  | year = 2003
  | page = 507
  | isbn = 0-619-06489-7
}}</ref> The plan is analogous to an architect's blueprint.<ref name="pis-ch12-p507"/>

===Performance objectives===
The systems analyst has the objective to deliver the right information to the right person at the right time.<ref name="pis-ch12-p513">{{cite book
  | last = Stair
  | first = Ralph M.
  | title = Principles of Information Systems, Sixth Edition
  | publisher = Thomson
  | year = 2003
  | page = 513
  | isbn = 0-619-06489-7
}}</ref> The critical factors to achieve this objective are:<ref name="pis-ch12-p513"/>
# The quality of the output. Is the output useful for decision-making?
# The accuracy of the output. Does it reflect the true situation?
# The format of the output. Is the output easily understood?
# The speed of the output. Time-sensitive information is important when communicating with the customer in real time.

===Cost objectives===
Achieving performance objectives should be balanced with all of the costs, including:<ref name="pis-ch12-p514">{{cite book
  | last = Stair
  | first = Ralph M.
  | title = Principles of Information Systems, Sixth Edition
  | publisher = Thomson
  | year = 2003
  | page = 514
  | isbn = 0-619-06489-7
}}</ref>
# Development costs.
# Uniqueness costs. A reusable system may be expensive. However, it might be preferred over a limited-use system.
# Hardware costs.
# Operating costs.

Applying a [[Systems development life cycle|systems development process]] will mitigate the axiom: the later in the process an error is detected, the more expensive it is to correct.<ref name="pis-ch12-p516">{{cite book
  | last = Stair
  | first = Ralph M.
  | title = Principles of Information Systems, Sixth Edition
  | publisher = Thomson
  | year = 2003
  | page = 516
  | isbn = 0-619-06489-7
}}</ref>

===Waterfall model===
The [[waterfall model]] is an implementation of a ''systems development process''.<ref name="se-ch1-8">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 8
  | isbn = 0-256-08515-3
}}</ref> As the ''waterfall'' label implies, the basic phases overlap each other:<ref name="pis-ch12-p517">{{cite book
  | last = Stair
  | first = Ralph M.
  | title = Principles of Information Systems, Sixth Edition
  | publisher = Thomson
  | year = 2003
  | page = 517
  | isbn = 0-619-06489-7
}}</ref>
# The ''investigation phase'' is to understand the underlying problem.
# The ''analysis phase'' is to understand the possible solutions.
# The ''design phase'' is to [[Software design|plan]] the best solution.
# The ''implementation phase'' is to program the best solution.
# The ''maintenance phase'' lasts throughout the life of the system. Changes to the system after it is deployed may be necessary.<ref name="se-ch11-345">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 345
  | isbn = 0-256-08515-3
}}</ref> Faults may exist, including specification faults, design faults, or coding faults. Improvements may be necessary. Adaption may be necessary to react to a changing environment.

===Computer programmer===
A [[computer programmer]] is a specialist responsible for writing or modifying the source code to implement the detailed plan.<ref name="pis-ch12-p507"/> A programming team is likely to be needed because most systems are too large to be completed by a single programmer.<ref name="se-ch10-319">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 319
  | isbn = 0-256-08515-3
}}</ref> However, adding programmers to a project may not shorten the completion time. Instead, it may lower the quality of the system.<ref name="se-ch10-319"/> To be effective, program modules need to be defined and distributed to team members.<ref name="se-ch10-319"/> Also, team members must interact with one another in a meaningful and effective way.<ref name="se-ch10-319"/>

Computer programmers may be [[Programming in the large and programming in the small#Programming in the small|programming in the small]]: programming within a single module.<ref name="se-ch10-331">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 331
  | isbn = 0-256-08515-3
}}</ref> Chances are a module will execute modules located in other source code files. Therefore, computer programmers may be [[programming in the large]]: programming modules so they will effectively couple with each other.<ref name="se-ch10-331"/> Programming-in-the-large includes contributing to the [[application programming interface]] (API).

===Program modules===
[[Modular programming]] is a technique to refine ''imperative language'' programs. Refined programs may reduce the software size, separate responsibilities, and thereby mitigate [[software aging]]. A ''program module'' is a sequence of statements that are bounded within a [[Block (programming)|block]] and together identified by a name.<ref name="se-ch8-216">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 216
  | isbn = 0-256-08515-3
}}</ref> Modules have a ''function'', ''context'', and ''logic'':<ref name="se-ch8-219">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 219
  | isbn = 0-256-08515-3
}}</ref>

* The ''function'' of a module is what it does.
* The ''context'' of a module are the elements being performed upon.
* The ''logic'' of a module is how it performs the function.

The module's name should be derived first by its ''function'', then by its ''context''. Its ''logic'' should not be part of the name.<ref name="se-ch8-219"/> For example, <code>function compute_square_root( x )</code> or <code>function compute_square_root_integer( i : integer )</code> are appropriate module names. However, <code>function compute_square_root_by_division( x )</code> is not.

The degree of interaction ''within'' a module is its level of [[Cohesion (computer science)|cohesion]].<ref name="se-ch8-219"/> ''Cohesion'' is a judgment of the relationship between a module's name and its ''function''. The degree of interaction ''between'' modules is the level of [[Coupling (computer science)|coupling]].<ref name="se-ch8-226">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 226
  | isbn = 0-256-08515-3
}}</ref> ''Coupling'' is a judgement of the relationship between a module's ''context'' and the elements being performed upon.

===Cohesion===
The levels of cohesion from worst to best are:<ref name="se-ch8-220">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 220
  | isbn = 0-256-08515-3
}}</ref>

* ''Coincidental Cohesion'': A module has coincidental cohesion if it performs multiple functions, and the functions are completely unrelated. For example, <code>function read_sales_record_print_next_line_convert_to_float()</code>. Coincidental cohesion occurs in practice if management enforces silly rules. For example, "Every module will have between 35 and 50 executable statements."<ref name="se-ch8-220"/>
* Logical Cohesion: A module has logical cohesion if it has available a series of functions, but only one of them is executed. For example, <code>function perform_arithmetic( perform_addition, a, b )</code>.
* ''Temporal Cohesion'': A module has temporal cohesion if it performs functions related to time. One example, <code>function initialize_variables_and_open_files()</code>. Another example, <code>stage_one()</code>, <code>stage_two()</code>, ...
* ''Procedural Cohesion'': A module has procedural cohesion if it performs multiple loosely related functions. For example, <code>function read_part_number_update_employee_record()</code>.
* ''Communicational Cohesion'': A module has communicational cohesion if it performs multiple closely related functions. For example, <code>function read_part_number_update_sales_record()</code>.
* ''Informational Cohesion'': A module has informational cohesion if it performs multiple functions, but each function has its own entry and exit points. Moreover, the functions share the same data structure. Object-oriented classes work at this level.
* ''Functional Cohesion'': a module has functional cohesion if it achieves a single goal working only on local variables. Moreover, it may be reusable in other contexts.

===Coupling===
The levels of coupling from worst to best are:<ref name="se-ch8-226"/>

* ''Content Coupling'': A module has content coupling if it modifies a local variable of another function. COBOL used to do this with the ''alter'' verb.
* ''Common Coupling'': A module has common coupling if it modifies a global variable.
* ''Control Coupling'': A module has control coupling if another module can modify its [[control flow]]. For example, <code>perform_arithmetic( perform_addition, a, b )</code>. Instead, control should be on the makeup of the returned object.
* ''Stamp Coupling'': A module has stamp coupling if an element of a data structure passed as a parameter is modified. Object-oriented classes work at this level.
* '' Data Coupling'': A module has data coupling if all of its input parameters are needed and none of them are modified. Moreover, the result of the function is returned as a single object.

===Data flow analysis===
[[File:Sandwich data flow diagram.pdf|thumb|A sample function-level data-flow diagram]]
''Data flow analysis'' is a design method used to achieve modules of ''functional cohesion'' and ''data coupling''.<ref name="se-ch9-258">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 258
  | isbn = 0-256-08515-3
}}</ref> The input to the method is a [[data-flow diagram]]. A data-flow diagram is a set of ovals representing modules. Each module's name is displayed inside its oval. Modules may be at the executable level or the function level.

The diagram also has arrows connecting modules to each other. Arrows pointing into modules represent a set of inputs. Each module should have only one arrow pointing out from it to represent its single output object. (Optionally, an additional exception arrow points out.) A [[Daisy chain (electrical engineering)|daisy chain]] of ovals will convey an entire [[algorithm]]. The input modules should start the diagram. The input modules should connect to the transform modules. The transform modules should connect to the output modules.<ref name="se-ch9-259">{{cite book
  | last = Schach
  | first = Stephen R.
  | title = Software Engineering
  | publisher = Aksen Associates Incorporated Publishers
  | year = 1990
  | page = 259
  | isbn = 0-256-08515-3
}}</ref>