Software Engg

Prepared by Zubair Ahmed

-1–

Prepare by Zubair Ahmed

S O FT WA R E E N G I N E E R I N G S O F T WA R E : S O F T WA R E =

Programs + Documentation required to develop, operate and

maintain programs.

Documentation is an essential component of software because it is not possible to understand different aspects of large programs without documentation. And in the words of Goethe: “What we do not understand we do not possess.” Most programmers regard documentation a necessary evil. But this idea is not correct. In large systems the effort required to write documentation is often as great as that required to develop programs.

S O F T WA R E E NG I N E E R I N G :

Prepared by Zubair Ahmed

-2–

Software Engineering is an engineering discipline concerned with the practical problems of developing large software systems.

Efficient and economical

development of large software systems is perhaps the central problem of Software Engineering. A large software system incorporates a variety of human interests and activities and its development is beyond the capabilities of a single individual. Such a system needs an organised group of specialised people to design, implement, test and maintain it. After coming into operation large systems tend to have long lives because their development is very large expensive and it is not economical to replace them by a new system. Instead they are modified to fix bugs, to increase efficiency and to cope with the changing requirements.

The

modifications and extensions tend to deteriorate the original structure of the system and may introduce new errors. In the words of Arango et al: “Over its life time a system is disected, modified and sewn back together until its form is beyond recognition. Horror stories of these software Frankenstein are well known to the practitioners.“ Software systems are the most intricate and complex of man’s handiwork whose complexity increases with size much more than linearly. A large system is developed by many people perhaps at different sites, therefore, its development is not merely a programming problem but it also a management problem. The term “Software Engineering” was introduced in late 1960’s at a conference held to discuss what was then called “Software Crisis”. This crisis resulted directly from the introduction of the “Third Generation” hardware. This hardware was very powerful as compared to their “Second Generation” counterparts and their power made development of unrealisable applications a feasible proposition.

The implementation of these applications

required large systems to be built. Early experiences in building large software systems showed that existing methods of Software Development were not good enough.

The techniques

applicable to small systems could not be scaled up. Major projects were sometimes years late, cost much more than originally estimated, were unreliable, difficult to maintain and performed poorly.

Hardware costs were decreasing while the software costs were increasing.

techniques and methods

New

Prepared by Zubair Ahmed

-3–

were needed to control the complexity inherent in large software systems. Now, even in 1990’s the software Crisis is not resolved. Although there have been real improvements in Software Engineering methods and techniques, in tools for the software development and in skills of development staff, the demand for the software is increasing faster than the improvements: We needed: Better technology. Better education and training of software engineers. Software Engineers should be professionals who use theory from other disciplines and apply this in a cost-effective way to solve difficult problems.

W E L L E N G I N E E RE D S O F T WA R E : A well engineered software: Should be maintainable; i.e. it should be designed and documented in such a way that it could be modified/enhanced without undue cost. Should be reliable; i.e. it should perform according to the expectations of the users and should not fail very often. Should be efficient; i.e. it should not make a wasteful use of resources such as memory & CPU. Should offer an appropriate user interface; if a software system has not a good user interface it cannot be used to get maximum out of it. It should be noted that it is the interface through which are accessed the facilities provided by a software system.

THE SOFTWARE PROCESS

(LIFE CYCLE)

The identification of the software development as an engineering discipline led to the need of a “Software Development Model” or “Software Life Cycle”. The detailed model is still the topic of research but it is now clear that a number of general models or paradigms of software development can be identified. Some of these models are:

Prepared by Zubair Ahmed

THE

-4–

WAT E R - FA L L A P P R OA C H :

This approach views the software life

cycle as made up of a number of stages such as: requirements specification, software design, implementation and so on. After the completion of one stage the development proceeds to the next stage.

E X PLO R AT O RY P R O G R AM M I N G : This approach involves developing a working system as quickly as possible and then modifying that system until it works in an adequate way. This is used in the development of AI systems where the users can not formulate a detailed requirement specification and where adequacy rather than correctness in the aim of designers.

P R O T O T Y P I N G : This approach is similar to exploratory programming in that first phase involves the quick development of a program for user’s experiment. But here the objective is to establish the system requirements.

This is developed from an outline

specification. The users experiment with the prototype to refine and improve the specification. This is followed by the re-implementation of the software to produce a production quantity system.

F O RM A L T R A N S F O R M AT I O N : This approach involves developing a formal specification of the system and transforming this specification to a program using correctness - preserving transformations.

Each transformation is sufficiently close to the

previous description that effort of verifying the transformation is not excessive. It can then be guaranteed that the developed program is the true implementation of the specification.

S Y S T EM A SS E M BLY

FR O M

R E - U S A B L E C O M P O N E N T S : This

approach involves developing software system from the existing components. Thus the system development process becomes one of the assembly rather than creation. The first three of these approaches are all being used for practical system development. Some systems have been built using formal transformation but this is still an untried approach. The re-use-oriented model is still not commercially viable because of the lack of reusable component libraries. THE WATERFALL MODELS OF THE LIFE CYCLE

Prepared by Zubair Ahmed

-5–

This model is illustrated in the figure below. Because of the cascade from one stage to other this model is called waterfall model. This is also called “Classic Life-Cycle”. This model is the oldest and widely used one.

Requirements Analysis and Definition

R E Q USystem I R E M E and N T S A N ALY S I S

A N D D E F I N I T I O N : The system’s Software Design services, constraints and goals are established by consultation with the system users. They are

then defined in a manner which is understandable by the users and the development staff. Implementation and Unit Testing Integration and System Testing

Fig. The Waterfall Model of Software Development

Operation and Maintenance

Prepared by Zubair Ahmed

S Y S T EM

-6– AND

S O F T WA R E D E S I G N :

The system design process

partitions the requirements either to hardware or to software systems and establishes an overall systems structure. The software design involves representing the software system functions in such a way that may be transformed to one or more executable programs. Software design is a multistep process that focuses on four attributes of a program. These are:

Software architecture Interface Data structure Procedural details Design process translates requirements into representation of the software. Like requirements, design is also documented and it becomes apart of software configuration.

I M P L EM E N TAT I O N

AND

U N I T T E S T I N G : In this stage the software

design is realised as a set of working programs or program units. The unit-testing means verifying each unit that meets its specifications and it is verified that the defined input produces the desired results.

I N T EG R AT I O N

AND

S Y S T EM T E S T I N G : The individual program

units or programs are integrated and tested as a whole system to ensure that software requirements are met. After testing the system is delivered to the customer.

O P E R AT I O N & M A I N T E N A NC E : Normally (not necessarily) this is the longest phase of the life cycle.

The system is installed and put into practical use.

Maintenance involves correcting errors, which were not detected in earlier stages of the life cycle, improving the implementation of the system units and enhancing the system’s services as new requirements are discovered.

Prepared by Zubair Ahmed

-7–

It is useful for the management if all the stages are distinct. In practice the stages overlap and feed information to each other. For example, during design problems with requirements are identified, during coding design problems are found and so on. Thus the software development process is not a simple linear model but involves a sequence of iteration of the development activities. But this model makes it difficult for the management to

Requirements Analysis and Definition System and Software Design Implementation and Unit Testing Integration and System Testing Operation and Maintenance Fig. Iteration in the Waterfall Model

Prepared by Zubair Ahmed

-8–

identify definite checkpoints.

Thus tendency is to freeze a part of

development after a small number of iterations and to continue with the next development stage. Problems are, either left for later resolution, ignored or programmed around. This premature freezing of requirements may mean that the system will not do what the user wants. It may lead to badly structured systems as the design problems are circumvented by the implementation tricks. The testing of the system when it is complete is the ultimate validation phase. At this stage the system developer must convince the system buyer that the system meets the requirements. However, the verification and validation should be part of earlier life cycle stages. During verification and validation, the information is fed back to the earlier stages. According to Boehm (1981) Verification:

Are we building the product right?

Validation:

Are we building the right product?

During the final phase of life cycle (Operation and Maintenance), the information is fed back to the previous development phases. In this phase the software is used, errors and omissions in the requirements phase are discovered, program and design errors come to light and the need for new functionality is identified. Modifications become necessary for the software to be useful.

Making these changes is usually called Software Maintenance. Maintenance may involve changes is requirements, design & coding and may need further systems testing. The development process or a part of it is repeated as modifications are made. An aim of software engineering is to reduce overall software costs so the cost distribution across the software process must be known. Unfortunately for anything apart from the conventional waterfall model, the development costs are not broken down. Even for systems developed using a conventional approach costs vary dramatically depending upon the application, development organization & development costs. Sometimes the cost information is commercially sensitive. If available, only a few organizations are ready to publish the costs. It is very difficult to obtain an overall picture of development costs for the Software Industry. Following are the figures given by Boehm (1975) for different systems:

Prepared by Zubair Ahmed

-9–

S Y S T EM T Y P E

P H A S E C O S T S (%)

Req / Design Implementation

Testing

Command & control Systems

46

20

Space-born Systems

34

20

46

Operating Systems

33

17

50

Scientific Systems44

26

30

Business systems 44

28

28

34

Fig. Life cycle cost distribution. It is clear that software development costs are more at the beginning & at the end. Thus the software development costs an be reduced by: More effective requirements assessment & design. More effective verification & validation. These requirements have promoted other approaches to software development where the emphasis is on: Requirements: Validation:

(Prototyping Model) & (Formed Transformation Model)

N O T E : The costs of the systems developed by using exploratory programming are not covered by these figures. Above figure does not give any information about the maintenance costs. Again there is an immense variation from system to system. For most large, long life systems maintenance costs usually exceed the development costs by a factor of 2 to 4. But these may be greater. The waterfall model is not considered an adequate model because: It does not recognise the role of iteration in the software process. It implies that specifications should be frozen at an early stage This leads to software systems whose functionality does not match the one required by the users.

Prepared by Zubair Ahmed

- 10 –

Exploratory Programming Model & Prototyping Model try to resolve these difficulties.

What are major problems with “Waterfall Model” / ”Classic Life Cycle”? Ans. 1. Real projects rarely follow the linear flow of this model. Iteration always occurs and creates problems in the application of this model. This model expects that the requirements be stated explicitly in the beginning. But this is not possible for the customers. Customer must have patience. The working programs become available only at the end of the project. A major mistake, if undetected, can be disastrous. But in spite of its weaknesses this model is batter than other models. EXPLORATORY PROGRAMMING This is based on the idea of developing an initial implementation, exposing it to the user and refining this through many stages until an adequate system has been developed. This method is suitable to develop systems for which it is difficult (or impossible) to establish systems specifications at the earlier stages, such as AI systems.

Use Software System

Develop Outline Spec.

Build Software System

N o

Is Adequate

Yes

Deliver the System

Prepared by Zubair Ahmed

- 11 –

This method requires rapid development of the system & rapid incorporation of the modifications. To accomplish thus: A very high-level programming language such as LISP or PROLOG is required. Powerful dedicated hardware is required. Integrated set of tools for the development of software is required. Its main difference from the other approaches is in the verification & validation: Without a specification verification is impossible because for this purpose the program is composed of its specifications. The notion of correctness is replaced by the notion of adequacy. It has been mostly used to develop AI systems & has been little used in the development of large, long life systems because : It is not economical to produce a great deal of documentation as the system goes on changing regularly. This results in a system whose structure is not well defined and if there is any it gets deteriorated. Thus the maintenance costs are high (particular when the system maintainers are different from the system developers). The skills of the developing team can not be used effectively. These difficulties do not mean that exploratory programming should be rejected. There are some systems, which can not be developed by setting out specifications & then constructing the systems according to specifications. In such cases it is the only reasonable development technique. One possible approach might be to develop a prototype using exploratory programming and use this as a basis for a system developed in a more structured way.

Prepared by Zubair Ahmed

- 12 –

Explain why programs, which are developed using an exploratory programming approach, are likely to be difficult to maintain? What is difference between verification and validation? Illustrate your answer with examples of each of these activities.

MANAGEMENT PROCESS MODELS Software engineering is also concerned with the management problems of a team developing a software. A model of the software life cycle is acceptable only if it does not result in an unmanageable process. The management cannot assess the progress by looking at the work, therefore the management relies on a model which makes the process visible by means of documents. This has led to a “Deliverable Oriented Model”. In this model again, a process is decomposed into stages and at the completion of each stage a document is produced, reviewed and accepted. The output of one stage acts as input for other. “The waterfall model is one of the deliverable models”. Fig shows one possible way of splitting it into stages and the deliverables, which should be produced at each stage. ACTIVITY OUTPUT DOCUMENT Req. Analysis

Feasibility Study, Outline Requirements

Req. Definition

Requirements Spec

System Spec.

Functional Spec., Acceptance Test Spec.

Architectural Design Interface Design Coding

Draft User Manual, Design Spec., System Spec.

Interface Spec., Integration Test Spec.

Program.

Unit Testing

Unit Test Report.

Model Testing

Model Test Report.

Integration Testing System Testing

Integration Test Report. System Test Report.

Acceptance Testing

Final system.

The problems with the document-based models are:

Prepared by Zubair Ahmed

- 13 –

Management requires documents at regular intervals. Timings of the management requirements may not coincide with activity completion. The need to approve documents constrains the process iteration. The notion that output of one stage acts as input for the other implies that process is linear. But in actual practice at any point a software engineer considers the earlier and future stages. A design, which is difficult to implement, is not desired even if it meets the requirements. A lot of time is spent on documents, which tends to make the system expensive. Time required to review the document is significant and a phase starts before the documents of the previous phase are complete. Certain problems simply cannot be tackled by creating a detailed specification, then design then an implementation & so on. In some projects the blind use of this model has resulted in high prices. The waterfall model has been adopted as a general standard by many government agencies (software procures). It can not be simply rejected, inspite of these difficulties. Some improved model for management which satisfies the requirements of the procurers & is based on the different generic models. The best alternation is “RISK BASED” on “SPIRAL MODE”.

This is illustrated in fig.

Its key characteristic is the assessment of

management risk items at regular stages andRisk initiation Analysis of actions to counteract these risks. Before each cycle a risk analysis is initiated and at the end of each cycle a review procedure Risk Analysis whether to move on to the next cycle of the spiral.

Operational Prototype

Prototype3

Risk Analysis

Review

Prototype2

Risk Analysis

Prototype1

Request Plan, Life Cycle Plan Concept of Operations Development Plan

Integration & Test Plan Plan next phase Operation

Simulation, models, benchmarks

S/W Requirements Requirements Product Validation Design Design Implementation & Verification & unit testing Integration test Acceptance test Service

Detailed Design

Prepared by Zubair Ahmed

- 14 –

Risk cannot be defined precisely. A good way to think of the risk in a model is simply something, which can go wrong. For example, if the intention is to use a new programming language a risk is that no suitable compiler is available. Risks are consequences of inadequate information and are resolved by initiating some actions to discover information, which reduces the uncertainty. In above example, the risk would be resolved by a market survey to find which compilers were available. If no suitable system were available the decision would have to be changed. A cycle of the spiral begins by elaborating objectives such as performance functionality. Alternative ways of achieving these objectives are then enumerated. Each alternative is then assessed against each objective. This results in the identification of the sources of the project risk. The next step is to evaluate these risks by activities such as more detailed analysis, prototyping simulation etc.

Prepared by Zubair Ahmed

- 15 –

After risk evaluation a development model is chosen. If user interface risks are dominant then appropriate model is prototyping & if safety risks are dominant then formal transformation model is appropriate. Waterfall model is most appropriate if the identified risk is the subsystem integration. It is not mandatory to adopt a single model for whole of the life cycle of the system. Spiral model encompasses other process models. Prototyping may be used in one cycle to resolve the requirements risk and this may be followed by a conventional waterfall model. Formal transformation can be used for the critical parts of the system and reuse oriented model can be used during the implementation of the user interface. The originator of this model, (Boehm) suggests that a form be filled in for each round of the spiral. To illustrate this a form for the development of “Reusable Components Catalogue” is shown in the following figure.

Prepared by Zubair Ahmed ObjectivesProcure

- 16 – software

components

catalogueConstraintsWithin

a

yearMust support existing componentsTotal cost less than Rs.3mAlternativesBuy existing information softwareBuy a database and develop catalogue using query languageDevelop special purpose catalogueRisksMay be impossible to procure within constraintsCommission consultant report on existing information retrieval systemsRelax time constraintResultsInformation retrieval systems are inflexibleIdentified requirements cannot be metPrototypes developed using DBMS may be enhanced to complete the systemSpecial purpose catalogue development is expensive.PlansDevelop catalogue using existing DBMS by enhancing prototype & user interfaceCommitmentFund further 12 months developmentThe risk assessment for the catalogue can then be developed in more details, user interface requirements. As it is clear that risk driven approach can accommodate other models such as evolutionary prototyping. By identifying and assessing the risks most appropriate models can be used. Indeed different models can be used for the development of the different parts of the same system. E X E RC I S E : An education board intends to computerise its examination system. The system holds all details of registered students including personal information, courses taken and examination marks achieved. The alternative approaches to be adopted are: Buy a DBMS and develop an in-house system based on this database. Buy a system from another board and tailor it to local requirements. Join a consortium of other boards, establish a common set of requirements and contract software house to develop a single system for all of the boards in the consortium. Identify two possible risks in each of these strategies and suggest techniques for risk resolution which would help in deciding which approach to adopt. What is the distinction between verification & validation. Illustrate your answer by an example.

Prepared by Zubair Ahmed

- 17 –

FUNCTIONAL

A ND

NON FUNCTIONAL REQUIREMENTS

FUNCTIONAL REQUIREMENTS: Requirements describe a system’s behaviour. These are the services which the system is expected to provide to the user. The user is not interested in how these services are implemented so the software engineer should avoid the implementation details in the description of these requirements. NON - FUNCTIONAL REQUIREMENTS: These set out the constraints under which the system must operate and the standards, which must be met by the system, e.g. a non-functional constraint might be “input should be expressible using ASCII character set”. Actually, a non-functional constraint imposes a restriction, which limits our choice of constructing a solution. A standard, which must be met by the system, might be “the maximum system response time for any user command should be less than 2 seconds”.

C HARACTERISTIC S

OF

R EQUIREMENTS :

The requirements describe not only the flow of information

to

transformation

constraints

and

from

the

system

and

of data by the system but also the

under which the system must operate.

Thus the requirements can serve three purposes: They allow the developers to explain their understanding of how the customer wants the system to work.

Prepared by Zubair Ahmed

- 18 –

They tell the designers what functionality and the characteristics the resultant system is to have. They tell the test team what to demonstrate to convince the customer that the system being delivered is indeed what was ordered. In particular, the standards set out must be quantifiable measures. As the requirements are used both by the customer and the system developer, it is necessary to validate the requirements. The

validation process checks for

seven criteria:

Are the requirements correct?

The requirements should be

reviewed by the customer and software engineer to check that theSy are stated without errors.

Are the requirements consistent?

No one requirement

should conflict any other.

Are the requirements complete?

This means that all

services required by the user are specified. If the requirements description contains all the things desired by the user then it is said to be “externally complete”. A description is internally complete if there are no undefined references within the requirements.

Are the requirements realistic?

Can the goals set by the

user be possibly achieved? (e.g. It is impossible to have the same response time for local and remote users).

Do the requirement describe what is needed by the customer?

“What the user needs often differs from what he thinks he needs”.

Are the requirements verifiable?

Can tests be

written so that one can demonstrate that requirements have been met?”.

Are the requirements traceable?

Can each system function be

traced to a set of requirements that mandate it? Is it easy to find a set of requirements, which deal with a specific aspect of the system?

Prepared by Zubair Ahmed

- 19 –

In practice, for large software systems it is practically impossible to have completeness and consistency in the initial version of the requirements-document. It must be correct after having the feedback from later stages.

H OW

TO

W RITE

R EQUIREMENTS

D EFINITION : It is a normal practice to express the requirements-definition using a mixture of natural language, tables and diagrams. In spite of the developments in the specification techniques the first version of the requirements-definition is in a natural language (English or customer’s language). However, it has become clear that there are several problems with using natural language. These include: Ambiguity; different parties interpret the same terms differently. Requirements are not easily separated according to the system elements with which they deal. It is sometimes difficult to trace back from a system characteristic to the requirement that define or affect it.

A natural language requirements-definition should be complemented by a requirements specification in a structured language. Comments should be included in this specification for the non-technical people. The definition should concentrate on concepts and refer the reader to the specification for more detailed information. The definition concentrates on describing the facility required and justifying why it is required. This rationale is critical if the requirements document is to be properly understood and is to be an effective system description for software developers. Without a rationale some facilities appear arbitrary and the developer may not understand their importance. It is easy to criticise a requirements definition but much more difficult to write such a document. The writer has a mental model of what is required and has formed a variety of informal relationships within the model. The natural tendency is to express these relationships as these are discovered so that information is not accidentally omitted. The first version is inevitably unstructured.

Prepared by Zubair Ahmed

- 20 –

The most useful approach is to invent a standard format and to ensure that the definition adheres to that format. The descriptive paragraphs might be followed by a rational and a reference to more detailed specification. A X I O M AT I C D E F I N I T I O N : The system is expressed in terms of axioms. The basic system properties are specified and the behaviour of the system generates new properties from them. The new properties are called theorems. This method demands that axioms are complete and consistent otherwise the resulting theorems will not express truths about the system. This method is well suited to the requirements definition of the expert systems. Axiomatic definition is often used in specifying abstract data types. The system is described as a set of objects and a set of operations on those objects. The axioms specify the relationship between the objects and operations. R E Q U I R E M E N T S S P E C I F I C AT I O N : Requirements specification is the technical counterpart of the requirements definition. In this case the contents of requirements definition are restated in technical terms appropriate for the system design. Requirements specification also forms the basis of contract between the procurer

and developer. Requirements specification is also called “ functional specification”.

Many of the problems of software engineering are difficulties with the

requirements specification. The cost of errors in stating requirements may be very high, particularly if these are not detected until the implementation of the system. The cost of implementing a requirements change, whether it is due to error or inconsistency can be up to one hundred times of fixing a bug in implementation.

METHODS

FOR

W R I T I N G R E Q U I R E M E N T S S P E C I F I C AT I O N S

S T R U C T U R E D L A N G U A G E S P E C I F I C AT I O N : Many notations have been developed which use natural language in controlled way using a standard form for requirements specification.

Prepared by Zubair Ahmed

- 21 –

A form-based approach to requirements specification may be structured around the objects manipulated by the system, the functions performed by the system or the events processed by the system. But functionally oriented specifications are probably the most common. An example of such specification for a part of ATM system is shown in the fig. Function: Check-card-validity Description:

This operation must ensure that the card input by a user has

been issued by the subscribing bank, is in date, contains appropriate account information and includes the details of date and amount of previous cash withdrawal. Inputs:

Bank-identifier, Account-number, Expiry date, Last transaction

date, and Last transaction. Source:

Input data is read from the card magnetic stripe.

Outputs: Card-status = (OK, Invalid) Destination:

Auto Teller. The card status is passed to another part of the

software. Requires: Bank-list, Account-format, and Today’s-date. Pre-condition:

Card has been inserted and data has been read.

Post-condition:

Bank-identifier is in the bank-list, Account No. matches the

account format and expiry date >= Today’s date

and last transaction date <= Today’s date and card-status = OK AND (if any of these tests fails then) Card-status = Invalid Side effects:

None.

This specification uses pre and post conditions to specify the actions of the function. It uses a number of names (Bank-list, Account-format etc.) which must be defined elsewhere in the specification. This does not include any sequencing information - the tests may be carried out in any order.

Prepared by Zubair Ahmed

- 22 –

This method eliminates some of the problems of natural language specification; i.e. specification is structured but the ambiguity is still there. The other approaches eliminate this problem at the expense of readability. A formal mathematical specification can be defined from the structured forms.

(I) PROTOTYPING:

Q:

What is a Prototype? Why do we need a Prototype?

Ans: The prototype is all or part of the system that looks like the system under consideration but does not have the complete functionality of the real system. In this case sections of the proposed system are built quickly to determine the necessity, desirability or feasibility of the requirements. We need a Prototype to validate the requirements. Sometimes the customer is not certain what he exactly need. Sometimes customer is certain of what he need but we are not certain whether the requirements are realistic or not.

The potential user may have

difficulty in imagining how the system would work.

Q:

How does a Software prototype differ from a Hardware prototype?

Ans: Actually objectives are different. In the case of hardware prototype the objective is to validate the design. First the electronic design is realised and tested by using off the shelf components, which are then replaced by expensive production quality IC’s after the satisfactory performance of the prototype. While in case of software prototype the objective is to validate/refine the requirements.

Q:

What are the benefits of developing the prototype?

Prepared by Zubair Ahmed

- 23 –

Ans: Misunderstandings between the user and the system developers are identified.  Missing user services may be detected.  Confusing user services may be identified and refined.  Development staff may find incompleteness inconsistencies in requirements.  A working system is available quickly, which can be used to demonstrate its usefulness to the management.  Prototype reduces the risk of errors in the requirements, which can be expensive.  It serves as a basis for writing the final version of the requirements specifications. It can also has two other uses:  As it is similar to the actual system, it can be used for staff training (who would operate the system).  It can be used to run back to back tests with the actual system. It is an important technique for requirements-validation. A prototype software system may be developed from outline specification. Users experiment with the prototype to refine and improve the specification. Experiments have shown that prototyping reduces the number of problems with requirement specifications. Overall development costs may be lower if a prototype is developed. The potential user may have difficulties in imagining how does the system work. Having only requirement specification in hand the user may have difficulties in imagining how does the system would work. One way to counter this difficulty is to develop a system prototype and to allow the user to experiment with it. In this way user can discover errors and omission in the requirements.

S TA G E S

IN THE

P R O T O T Y P E D E V ELO P M E N T :

There are four stages in the prototype development: 1.

E S TA BL I S H

PROTOTYPE OBJECTIVES:

 User interface

i.e. why we are developing the prototype?

Prepared by Zubair Ahmed

- 24 –

 Develop requirements  Demonstrate feasibility 2.

S E L EC T F U N C T I O N S : i.e. what to be included in prototype and also decide which nonfunctional requirements must be prototyped. Error handling management may be left out a prototype for a subset of function is developed.

3. D E V ELO P 4.

E VALUAT E

PROTOTYPE: THE PROTOTYPE SYSTEM:

User must be given enough training and time

to become comfortable with the system. He should experiment with it and feedback.

Q:

How does the prototype development effect the overall cost of a product?

Ans: A common argument against prototyping is that its cost is an unacceptably large fraction of the total system costs. It may be more economic to modify a finished system to meet the unperceived needs that to provide the user with the opportunity to refine and understand his needs. It has been observed that prototype development reduces the overall cost of a product because:  Errors and omissions are detected earlier  Effective prototyping increases software quality and gives developers a competitive edge over competitors. 

“Build it cheap and fix it latter” philosophy has failed in case of U.K and U.S automobile industry while Japanese succeeded due to Prototyping.

P R O T O T Y P I N G T EC H N I Q U E S : The main objective is the rapid development of a working system (prototype). This minimises the prototype costs (software staff salaries) and enables early feedback. There are four methods for Prototype Development:  Executable specification languages  Very high level languages

Prepared by Zubair Ahmed

- 25 –

 Fourth generation languages  Composition of reusable compounds

E X EC U TA B L E S P E C I F IC AT I O N S L A N G UAG E : A formal specification is a mathematical system model, which may be executable. The cost of producing a specification from the prototype is negligible. The code of the prototype is system specification. But this is not understandable by the users and there is a need to derive descriptive specification from it. There is still a need to derive descriptive specification from its mathematical equation. The prototype development may not be rapid. Formal specification requires a detailed system analysis and much time may be devoted to the detailed modelling of the system. The executable system is also slow and inefficient. Functional languages like ML (Meta-Language - Edinburgh), Z, CDL (Computer Description language - designed specially for specifications), Larch family of languages & Miranda are used. A functional language relies on expressing the system as a mathematical function. Functional languages are very high level languages. They allow a very concise expression of the problem. Because of their mathematical basis a function program can be viewed as a formal system specification. However the execution of functional programs on sequential Hardware is slow. Functional languages are most suitable for writing executable specifications.

Functional

languages are executed sequentially and their execution is very slow.

V ERY H I G H L E V E L L A NG UA G E S (F I F T H G E N E R AT I O N

L A N G UA G E S ):

These languages have inherent dynamic data structures and high level features like Backtracking. These include LISP (LISt Processing - based on list structures), Prolog (PROcess LOGic - based on logic) APL (A Programming Language - based of vectors) and SETL (SET language - based on sets). These languages require huge runtime environment and thus are not suitable for large programs, systems. These are suitable for prototypes or small programs. Lisp and Smalltalk have better environment Most of these languages are based on a single paradigm (concept), e.g. LISP handles functions and lists only; Pascal is imperative language; and Prolog is used for facts and logical systems. LISP and SmallTalk have better environment.

Prepared by Zubair Ahmed

- 26 –

Thus, a wide spectrum language like GIST is required, which describes a system as a finite state model. A wide spectrum language may include objects, logic programming and imperative constructs. GIST forces us to see the system as a set of “states and actions”. So we can write specifications in this language. Its commercial derivative REFINE is also available which is perhaps the wide spectrum language. It is a non-deterministic language in which the user writes the executable specification. This specification is refined by the user to produce an automated prototype. The specifications written in GIST or REFINE can be processed to generate programs in LISP. An alternative approach is to use mixed language programming for prototype development. Its disadvantage is communication framework.

F O U RT H G E NE R AT I O N COMPOSITION

FR O M

L A NG UA G E S :

R EU S A B L E C O M P O N E N T S :

Prototypes can rapidly be created from the reusable components, provided their libraries are available. Best example of this approach is the Shell programming language available in several variants under UNIX. It provides facilities for combining commands, which operate on strings and files: e.g. grip, sat, find. Shell programs are advanced forms of DOS Batch files. Reusable components can only be used if it was kept in mind before their programming. Prototyping using the shell is limited because the granularity of software components is relatively coarse. Base around database relies on Software reuse where the routines to access database and generate reports commercial data processing, small, rewrite rather than structuring code of the prototype, cost affective system specification.

SYSTEM DESIGN Q:

What is a design?

Ans:

It is desired to build a new system due to any of the following reasons: 1. There is no existing system 2. The system is not working properly.

Prepared by Zubair Ahmed

- 27 –

To find a solution to this problem, we use some creative process. The output of this process is a description of the solution to our problem. This is called system design. There can be more than one solution to a problem. Design is a creative process. It cannot be learned from book. Design must be practiced and learnt by experience and study of existing systems. In system design the functions to be performed by the system are partitioned into Software Functions and Hardware Functions. Until recently, these decisions were not difficult to make because only standard hardware with known functionality could be used. As it is now possible to fabricate special purpose chips at reasonable costs, the borderline between hardware and software components is blurring. It is becoming increasingly cost effective to delay decisions about which functions should be implemented in hardware and which functions should be implemented in software. This implies that system architecture must be made up of stand-alone components, which can be implemented in either Hardware or Software. This is the aim of the designer who wants to build a maintainable system. From now onward we shall concentrate on the software design. A general model of a software design is a directed graph where the nodes represent the entities in the design such as processes, functions or types and links represent relations between these design entities. The target of a design process is the creation of such a graph where there are no inconsistencies and the relationships are legal ones. It is not usual for Software designers to arrive at a finished design graph immediately. The design process appears to be a process of adding formality as the design progresses with constant backtracking to correct, earlier, less formal design.

A general

form

of

design, which usually

Informal Idea

Informal Design

More Formal Design

emerges from such a design

process,

is

The Design Process

Finished Design

Prepared by Zubair Ahmed

- 28 –

hierarchical with cross-links at lower levels. These links appear because of the fact that design components created earlier are reused later.

Q:

What is practiced?

Ans:

In many organizations Software design is largely an ad hoc process. Given a set of requirements, usually in a natural language, an informal design is prepared. Coding then starts and the design is modified as the system is implemented. By the time the system is implemented the design has changed so much that its original design document is totally inadequate description of the system.

Q:

What is meant by a good design? 1. Should it allow efficient code to be produced? 2. Should it allow small, compact code to be produced? 3. Should it be the most maintainable design?

Ans:

We adopt the later criterion as the criterion of goodness. A maintainable design implies that cost of system changes should be minimized. This is possible only if the design is understandable and effects of the changes are local. Let us now investigate the characteristics of a good design.

1. M O D U L A R I T Y : Modularity implies decomposition of large system into modules so that each of them can be implemented independently. A module usually realizes a single and simple function of the system. It therefore encapsulates data types related to that function & operations on the data types. In this way changes related to this data type and the corresponding operations are localized in this module. Each module is provided with a well-defined interface for communication with the other modules. The interface to the whole system is structured from these interacting module interfaces. Modularity directly supports modifiability, reliability and readability.

2. A B S T R AC T I O N :

Prepared by Zubair Ahmed

- 29 –

An abstract data type is defined as a set of objects capable only of a certain kind of behavior which corresponds to a finite set of allowable operations on object of that type. Its implementation details are hidden. The user is provided with certain operations and only needs to know what the operations are supposed to do and not how they do it.

3. C O H E S I O N : It refers to the internal glue with which a module is constructed. A module is highly cohesive if all elements within the module are directed toward and essential for performing the same function. The following levels of cohesion (in order of increasing strength) have been identified. a) C O I N C I D E N TA L C O H E S I O N :

The parts of a module are not related but are just

bundled together. b) L O G IC A L

A SS O C I AT I O N :

Components which perform similar functions are

grouped together; e.g. a module may read all kinds of inputs (from floppy disk, tape, HD) regardless of where the input is coming from and how it will be used. c) T EM P O R A L C O H E S I O N :

The components which are activated at a single time

such as start up or shut down. d) P R OC E D U R A L C O HE S I O N :

The elements in a unit make up a single cohesion

sequence. e) C O M M U N I C AT I O N A L

C O H E S I O N : All the elements that operate on the same

input data or produce the same output. f)

SEQUENTIAL

COHESION:

The output of one element in the unit serves as

(becomes) input for another element. g) F U N C T I O N A L C O HE S I O N :

Each part of the unit is necessary for the execution

of a single function.

4. C O U P L I N G : It is an indication of the strength of interconnections between the program units. It is measure of how program units depend on each other. Two modules are highly coupled if there is a great deal of dependence between them.

Prepared by Zubair Ahmed

- 30 –

DESIGN ACTIVITIES A design process consists of a number of stages. These are called design activities. Output of each design activity is a specification. This specification may be abstract, formal specification, which is produced to clarify the requirements, or it may be a specification of how part of the system is to be realized. As the design process continues more and more details is added t the specification. The design activities and design descriptions (specifications) produced as results of these activities are illustrated in figure below. Requirements Specification The Design Activities Architectural Design

Abstract Specification

System Architecture

Software Specification

Interface Design

Component Design

Interface Component Specification Specification Design Products

DataStructure Design

DataStructure Specification

Algorithm Design

Algorithm Specification

Design Activities & Design Products Figure suggests that stages of the design process are sequential. In practice some design activities go in parallel. However the activities shown are essential in the design of large software systems: 1.

A RC H I T EC T U R AL D E S I G N :

The subsystems constituting the system and their

relationships are identified and documented. 2.

A B S T R AC T S P E C I F IC AT I O N : An abstract specification of the services to be provided by each subsystem and the constraints under which it must operate is produced.

3.

I N T E R FA C E D E S I G N : Interface of each subsystem with other subsystems is designed and documented. This specification allows the subsystem to be used without knowledge of its implementation.

4.

C O M P O N E N T D E S I G N : The services provided by a subsystem are partitioned across components in that subsystem.

Prepared by Zubair Ahmed 5.

- 31 –

D ATA S T R U C T U R E D E S I G N : Datastructures to be used in the implementation of a subsystem/component are designed in detail and specified.

6.

ALGORITHM DESIGN:

Algorithms used to provide services are designed and

specified. This process is repeated for each subsystem until the components identified can be mapped directly into programming language components such as packages, procedures or functions.

D E S I G N D E SC R I P T I O N A design acts as:  a basis for implementation  a communication medium between designers  a communication medium for maintainers It must be possible to view the design at a number of different levels of abstraction. There are three notations, which are widely used for the documentation of design: 1.

G R A P H I C A L N O TAT I O N S :

It gives a overall picture of the system by displaying

components and their relationships. 2.

P R OG R A M D E S C R I P T I O N L A N G UAG E S (PDL’S): These use control and structuring constructs based on programming language constructs. These also allow comments. These allow the intention of the designer to be expressed.

3.

I N F O R M A L T E XT : A lot of information associated with a design can not be expressed formally. Information about design rationales and non-functional considerations must be expressed using natural language text.

Generally, all of these notations should be used in describing a system design: Architecture and logical data design should be described by graphical notation. Design rationale is described using natural languages (comments) text. The interface design, datastructure design and Algorithm design are best described using a PDL.

Prepared by Zubair Ahmed

A P P R OAC H E S

TO

- 32 –

S Y S T EM D E S I G N

It is useful to separate a design into component parts called modules. A design module is a functional entity with a well-defined set of inputs and outputs. Thus each module can be viewed as a component of the whole system just as each room is a component of a house. A module is well defined if all the inputs are transformed to generate outputs. A design is then determination of modules and inter-modular interfaces that satisfy a set of requirements. These modules can be developed in two ways: 

By beginning with a high level view and dividing the system into modules (decomposition).



By beginning with data and objects and building modules from them. (This is called composition).

D EC O M P O S I T I O N (Function-Based Design): We begin by writing high level description of inputs their transformation and outputs. Then we refine and redefine top level into more detailed modules - the first level of decomposition. This process continues to 2nd … levels of decomposition until atomic components have been identified where each module performs operations on exactly one major datastructure. This function-based design is also called TopDown Design.

Top Level First Level of decomposition

2nd Level of decompositio

Prepared by Zubair Ahmed

- 33 –

C O M P O S I T I O N (Object-Oriented Design): We compose the system from object modules. An object module defines a data object and provides operations to handle that object. The object module can be visualized as a box containing data and related operations. The data cannot be accessed directly; instead the operations provided are used to access the object. Object-type Modules Object Modules

Data Types

Then we define object-type module or object class to describe a type of data. The result of building up from data and data types is also a set of modules. Object Oriented design is also called bottom up design.

Ex: What is common and what is different in function-based design and Object Oriented design.