Development of complex software systems
•How do we deal with complexity of software development?
Miller: “People can keep track of seven things, be they bits,
words, colors, tones, or tastes. Tentatively, therefore, we are
justified in assuming that our memories are limited by the
number of units or symbols we must master, but not by the
amount of information that these symbols represent.”
•Deal with complexity through decomposition,composition,
and abstraction
Decomposition: Large pieces are partitioned into smaller
pieces, each of which is implemented independently.
Composition: Combine smaller units that were separately
defined.
•What are these software pieces?
Programming languages support abstractions such as
procedures, modules, user-defined types, and objects.
Abstraction: An abstraction consists of just those essential
properties essential to a purpose.
•Information hiding: a technique for supporting various forms
of abstraction. It is usually practiced by controlling the
visibility of names. If a name is hidden within a part of a
program, it cannot be accessed from other parts of the
program.
Access control can make programs easier to read and
maintain.
Information hiding associated with procedures.
ECS140A, Winter’06Abstract Data Types, slide 1 c
Raju Pandey
Data Abstraction
•Data abstraction: a programming methodology that supports
modifiability, extensibility, re-usability, encapsulation, etc.
•Earlier approaches: Different applications, procedures,
programs access and modify a data structure.
Problems with this approach:
– Close coupling between application and data structure
– Unnecessar y duplication
– Poor support for re-usability
– Re-compilation and testing
Conclusions: Poor support for program development
•A key insight in program organization is that data and
operations go together.
– Restructure the way in which programs are specified:
Data Structure + Procedures that can modify/manipulate
them.
– Client/Server view:
Data abstractions: servers
Applications: clients
•Data encapsulation: create an encapsulated name space
with mechanisms for accessing entities inside this name
space.
ECS140A, Winter’06Abstract Data Types, slide 2 c
Raju Pandey
Module
•A module is a collection of declarations, typically including
both variables and procedures.
Serves as a black box with which the rest of the program
interacts through an interface.
•Two parts:
–Definition (public): The interface of a module can contain
types, variables, procedures, and so on.
Design questions: What should this part not contain?
–Implementation (private): Code for procedures, data
structure definitions, and code for initialization.
•Interface between modules via import/export mechanism
Export: determine what should be visible
Import: specify what is being used
•Roles of modules:
– Suppor t modularization
– Improve maintainability
– Increase potential for reuse
– Separate compilation
•Modules in Modula-2: module
•Modules in Ada: package
ECS140A, Winter’06Abstract Data Types, slide 3 c
Raju Pandey
Modules
•Added after class
•What should interface contain?
–Type names?
–Procedure signatures?
–Implementation?
–Can I control who can see what
•What should implementation contain?
•How can other modules use this module?
–How to import information?
–What if there is name conflict?
•Management issues
–Do specification and implementation go in the same file?
Different files?
–How does compiler find relevant specifications?
ECS140A, Winter’06Abstract Data Types, slide 4 c
Raju Pandey
