Software Issues Derived from Dr. Fawcett’s Slides Phil Pratt-Szeliga Fall 2009

Software Issues: Overview  Definitions  Software Design Objectives Overview Software Quality Deal with Complexity Management of Change Software Reuse Design in the Application Domain  Conclusions

Definitions  Unit – Smallest encapsulated piece of processing (function, method, procedure)  Information Cluster – A set of public and private units used for every access to hidden data with: Complex structure Sensitive Security Device Dependence  Class – A pattern for an information cluster providing declarations of types and accessibility of units and data in instances of a class  Object – An instance of a class

Definitions  Module – An implementation of an information cluster A single file in C#. Two files in C or C++ Structures functions and data into a public interface and a private implementation  Program – A set of modules which can be compiled and linked into one execution image  Software System – A collection of cooperating programs to achieve some goal May share data and/or resources

Software Design Objectives  Develop high quality software: Correct, Robust, Extendible and has reasonable performance  Reuse software components Use software again without modification  Manage change When changing one component we want to minimize effects on other components  Deal with complexity Support a hierarchy of layers and the partitioning of software into relatively independent components

Software Design Objectives  Support Software Design in the Application Domain Design in terms of processing activities rather than computer activities computer platform compiler application designer source code

Objectives: Software Quality  Correctness Program exactly performs in accordance to it’s specifications  Robustness Program can function under abnormal conditions on: Inputs, outputs, data transformations, environment  Extendibility Program can be adapted to meet other specifications

Objectives: Software Quality  Reusability Component can be reused without modification for new application  Compatibility Component can be combined, without modification, with other components  Performance Use of platform resources and elapsed time to complete task is as small as practical

Software Quality Factors: Assertions  Correctness Programs should be composed of small, relatively independent, functions and modules  Robustness Use encapsulation to trap errors and keep them from propagating throughout the system  Extendibility Compose programs of nearly independent modules which can be augmented with expanded functions and data records

Software Quality Factors: Assertions  Reusability Implementation details should be hidden behind simple, fixed and easily understood public interfaces  Compatibility Public interfaces should be well designed, providing standard sockets used to connect to other components  Performance Increasing modularity often diminishes performance due to overhead of passing data though public interfaces and the invocation of several function call layers

Objectives: Deal with Complexity  A 40 million SLOC operating system such as Windows XP is so complex that not one person can understand the entire thing.  It requires expert knowledge of diverse fields: Hardware interaction Protocol standards such as  file systems  networking  media Window managers Custom compilers Process scheduling Concurrency  Other large systems require knowledge of a complex application domain For example, medical imaging requires expert knowledge of physics and mathematics and numerical methods

Objectives: Deal with Complexity  Building large systems like an operating system or medical imaging system require consummate knowledge of the application domain and a though understanding of the platform and mastery of powerful but complex tools  That’s the easy part!  The hard part is to conceive, structure, design, implement and test a system so complex that it requires 500 person years to complete and yet achieve conceptual integrity

Dealing with Complexity: Modularity  The purpose of a module or class is to implement a small, simple, logical model  Modularization Purpose: Build a software system out of cohesive, reliable modules  Modularization consists of dividing a program into modules which can be compiled separately

Objectives: Management of Change  Changes occur in all phases of software development Analysis Design Implementation Integration Test  Changes occur due to: Instability of requirements Inconsistencies of interfaces Latent errors in coding Failure to satisfy performance and functional requirements  With modular design and encapsulation Changes do not have ripple effects

Objectives: Software Reuse  Hardware reuse has been widely accomplished Standard integrated circuits: multiplexors, ALUs, processors, memory, … Standard Boards: processor boards, communication boards  Reuse has not been nearly as successful in the software industry Reuse: Operating Systems, Compilers, Standard Libraries Most application code developed from scratch With Object Oriented Design we can build objects nearly equivalent to software integrated circuits

Objectives: Design in the Application Domain  Modules and Classes model logical behavior of real world entities  Internal complexity is hidden in private implementation  Names and behaviors of modules and classes should be based on: The application model (top level components) Specifics of a solution model (bottom level components)

Conclusions  Use modular structure for all but the simplest programs supports developing correct software  Keep functions and modules small and relatively independent supports correctness and extensibility  Encapsulate processing details behind public interfaces supports extensibility and robustness

Conclusions  Make public interfaces as simple and understandable as possible Supports software reuse  Make the interface conform to some to some abstraction (e.g. sales account) Choose names of public functions to support the abstraction Make processing support what a client would expect of the abstraction  Document the public interface in the source code Supports software reuse

References  Objectives: Software Quality slide adapted from: Object Oriented Software Construction, Bertrand Meyers, Prentice Hall, 1988