1. (a) Vidyalankaryou express what objects do in response ...vidyalankar.org/file/engg_degree/prelim_paper_soln/SemV/INFT/OOAD.… · 1113/Engg/TE/Pre Pap/2013/INFT/Soln/OOAD 2 Use

1113/Engg/TE/Pre Pap/2013/INFT/Soln/OOAD 1

Vidyalankar T.E. Sem. V [INFT]

Object Oriented Analysis and Design Prelim Question Paper Solution

There are several kinds of events, such as a signal event, a change event, and a time event. A signal event is the sending or receipt of information communicated among objects. A change event is an event that is caused by the satisfaction of a boolean expression. A time event is an event caused by the occurrence of an absolute time or the elapse of a relative time.

1. (a)

Fig.: State diagram for phone line with activities. State diagrams let you express what objects do in response to events.

Vidyala

nkar

Vidyalankar : T.E. − OOAD


Use case for new student: 1. Use case name : 1

2. Use case : New student

3. Actors : 3.1 Instructor 3.2 Centre supervisor

4. Precondtion : 4.1 Student should navigate to the system.

5. Flow of Events : 5.1 Registration 5.2 Login 5.3 View details 5.4 Pay fees by cc 5.5 Logout

6. Normal Flow : 6.1 New student register himself to the system. 6.2 Student logged in to the system.

6.3 Student able to see details about courses offered, schedule of the course, fee structure and get option for the apply to course.

6.4 Student can log out from the system. 7. Alternate Flow : 7.1 Registration flow.

7.1.1 System displays registration form to the student 7.1.2 Student fills the registration form and clicks on submit button. 7.1.3 system accepts the information and provide login id to the

Student. 7.2 Login flow

7.2.1 Student enters login id and get logged in to the system. 7.2.2 A home page of system is displayed.

7.3 View detail. 7.3.1 After login to the system student is able to view the courses

offered, schedule the courses, fee structure of the courses. 7.3.2 System provides option for apply to the courses.

1. (b)

1. (c)

Register

login

schedule

fee

assignments

marks

online tests

list of students

assign instructors

user name

password

CC pay total

Instructor

Centre supervisor

Student

Vidyala

nkar

Prelim Question Paper Solution


7.4 Pay fees by credit card flow. 7.4.1 System provides form to pay the fees of course online.

7.5 Logout flow 7.5.1 System provides logout option to logout system.

Sequence diagram for the we case of new student. (1) The Abstraction-Occurrence Pattern :

(a) Context (i) Often in a domain model you find a set of related objects (occurrences). (ii) The members of such a set share common information but also differ from each other

in important ways.

1. (d)

2. (a)

Vidyala

nkar



(b) Problem (i) What is the best way to represent such sets of occurrences in a class diagram?

(c) Forces

(i) You want to represent the members of each set of occurrences without duplicating the common information

(d) Solution

(e) Antipatterns :

(2) The General Hierarchy Pattern

(a) Context (i) Objects in a hierarchy can have one or more objects above them (superiors), (ii) And one or more objects below them (subordinates). (iii) Some objects cannot have any subordinates

(b) Problem

(i) How do you represent a hierarchy of objects, in which some objects cannot have subordinates?

(c) Forces

(i) You want a flexible way of representing the hierarchy (ii) That prevents certain objects from having subordinates (iii) All the objects have many common properties and operations

Vidyala

nkar



(d) Solution

(e) Antipattern (3) The Player-Role Pattern

(a) Context (i) A role is a particular set of properties associated with an object in a particular

context. (ii) An object may play different roles in different contexts.

Vidyala

nkar



(b) Problem (i) How do you best model players and roles so that a player can change roles or possess

multiple roles? (c) Forces

(i) It is desirable to improve encapsulation by capturing the information associated with each separate role in a class.

(ii) You want to avoid multiple inheritance.

(iii) You cannot allow an instance to change class (d) Solution

(e) Example

(f) Antipatterns (i) Merge all the properties and behaviours into a single << Player >> class and not have

<< Role >> classes at all.

(ii) Create roles as subclasses of the <<Player>> class. (4) The Singleton Pattern

(a) Context (i) It is very common to find classes for which only one instance should exist (singleton)

(b) Problem

(i) How do you ensure that it is never possible to create more than one instance of a singleton class?

(c) Forces

(i) The use of a public constructor cannot guarantee that no more than one instance will be created.

(ii) The singleton instance must also be accessible to all classes that require it (d) Solution.

Vidyala

nkar



(d) Solution :

(a) Patient-Doctor

2. (b)

Vidyala

nkar



(b) Pharmacy (c) Report Creation

Vidyala

nkar



Aggregation Aggregation is special kind of association. Aggregation is used to represent ownership or a whole/part relationship, and composition is used to represent an even stronger form of ownership. With composition, we get coincident lifetime of part with the whole. The composite object has sole responsibility for the disposition of its parts in terms of creation and destruction. In implementation terms, the composite is responsible for memory allocation and deal-location. Moreover, the multiplicity of the aggregate end may not exceed one; i.e., it is unshared. An object may be part of only one composite at a lime. If the composite is destroyed, it must either destroy all its parts or else give responsibility for them to some other object. A composite object can be designed with the knowledge that no other object will destroy its parts. Composition can be used to model by-value aggregation, which is semantically equivalent to an attribute. In fact, composition was originally called aggregation-by-value in an earlier UML draft, with "normal" aggregation being thought of as aggregation-by-reference. The definitions have changed slightly, but the general ideas still apply. The distinction between aggregation and composition is more of a design concept and is not usually relevant during analysis. Generalization In a form of relationship among use cases, a generalization/specialization relationship exists. A given use case may be a specialized form of an existing use case. The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general use case. This resembles the object-oriented concept of sub-classing, in practice it can be both useful and effective to factor out common behaviors, constraints and assumptions to the general use case, describe them once, and deal with it in the same way, except for the details in the specialised cases. Association An association is a structural relationship that describes a set of links, a link being a connection among objects. Aggregation is a special kind of association, representing a structural relationship between a whole and its parts. Graphically, an association is rendered as a solid line, possibly directed, occasionally including a label, and often containing other adornments, such as multiplicity and role names, as in Fig. Multiplicity Symbols indicating multiplicity are shown at each end of the association. The multiplicity indicates how many instances of the class at this end of the association can be linked to an instance of the class at the other end of the association. Fig. shows some examples of associations, showing their multiplicity.

3. (a)

3. (b)

3. (c)

3. (d)

Vidyala

nkar



Some techniques for gathering The first gathering technique, observation, is used to obtain subtle information that stakeholders may not think of telling you. The next three, interviewing, brainstorming and prototyping, are complementary techniques for actively asking for the opinions and knowledge of stakeholders as well as forcing the stakeholders to stretch their minds. Users participate in all four of these techniques, so they feel personally involved in the project. This sense of involvement means that they will more readily accept the final system.

i) Observation : You can read documents and discuss requirements extensively with users, but often only the process of observing the users at work will bring to light subtle details that you might otherwise miss.

In its simplest form, observation means taking a notebook and 'shadowing' important potential users as they do their work, writing down everything they do. You can also ask users to talk as they work, explaining what they are doing. In another variation, you can videotape the session so you can analyse it in more detail later.

Observation, and analysing the resulting information, can consume a large amount of time. Therefore, it is best done during the development of large systems, with which potential users will be performing complex tasks.

ii) Interviewing : Interviewing is a widely used technique. However, a well-conducted series

of interviews can elicit much more information than poorly planned ad-hoc interviews.

Firstly, plan to have as many members of the software engineering team interview as many stakeholders as possible.

Spread out the interviews over time and allow yourself several hours for each interview, even if you do not expect to use that much time. Time between interviews will allow you to analyse what you have heard and to think of additional questions. Leaving plenty of time ensures that if the interviewee is providing lots of information, you can let him or her continue.

Prepare an extensive list of questions, although do not be disappointed if there is not enough time to have them all answered in a given interview. • Ask about specific details such as maximums and minimums. • Ask about the stakeholder's vision for the future. • If a customer or user present concrete ideas for their view of the system, ask if they have

any alternative ideas, or ask how they would feel about alternative ideas you have. This will help ascertain how flexible they are.

• Ask what would be a minimally acceptable solution to the problem. • Ask for other sources of information.

iii) Brainstorming : The following is a suggested approach to organizing and running an

effective brainstorming session : 1) Call a meeting with representation from all stakeholders. Effective brainstorming

sessions can be run with five to 20 people. 2) Appoint an experienced moderator (also known as a facilitator) i.e., someone who

knows how to run brainstorming meetings, and will lead the process. The moderator may participate in the discussion if he or she wishes.

3) Arrange the attendees around the periphery of a table and give them plenty of paper to work with.

4) Decide on a 'trigger question'. This is a key step in the process. A trigger question is one for which the participants can provide simple one-line answers that are more than just numbers or yes/no responses.

5) Ask each participant to follow these instructions : (a) Think of an answer to the trigger question, no matter how trivial or questionable the

answer is ! (b) Write the answer down in one or two lines on a sheet of paper, one idea per sheet.

4. (a)

Vidyala

nkar



(c) Pass the paper to the neighbour on you left to stimulate his or her thoughts. (d) Look at the answers passed from your neighbour to the right and pass these on to

your left as well. Use the ideas you have read to stimulate your own ideas. 6) Continue step 5 until ideas stop flowing or a fixed time (515 minutes) passes. 7) Moving around the table, ask everybody to read out one of the ideas on the sheets that

happens to be in front of them. 8) After a fixed time period, or after all ideas have been recorded on the flip chart, the group

may take a series of votes to prioritize them. For example, every person may be given a fixed number of votes that they can allocate to the answers they think are the most important.

iv) Requirements Documents : To perform good software engineering. It is always appropriate

to write down requirements. But the level of detail of the requirements can vary significantly from project to project. At one extreme, there are documents that informally outline the requirements using a few paragraphs or simple diagrams.

Frequently, you have to produce several requirements documents, each describing a different part of the system or a different level of detail. When doing this, you strategy should be to make them all complementary. Each should refer to other documents as necessary, but there should not be redundancy between the documents. Redundancy leads to contradictions when changes are made in one place but not another.

Class Diagrams A class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces. It is the backbone of almost every object oriented method, including UML. They describe the static structure of a system. Basics : Suppose given a task of drawing a family tree. The following steps would be taken : Identify the main members of the family Determine how they are related to each other Identify the characteristics of each family member Find relations among family members Decide the inheritance of personal traits and characters A class diagram is similar to a family tree. A class diagram consists of a group of classes and interfaces reflecting important entities of the business domain of the system being modeled, and the relationships between these classes and interfaces. The classes and interfaces in the diagram represent the members of a family tree and the relationships between the classes are analogous to relationships between members in a family tree. Interestingly, classes in a class diagram are interconnected in a hierarchical fashion, like a set of parent classes (the grand patriarch or matriarch of the family, as the case may be) and related child classes under the parent classes. Similarly, a software application is comprised of classes and a diagram depicting the relationship between each of these classes would be the class diagram. A class diagram is a pictorial representation of the detailed system design. Design experts who understand the rules of modeling and designing systems design the system's class diagrams. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system. Use cases talk about "what are the requirements" of a system. The aim of designing classes is to convert this "what" to a "how" for each requirement. Each use case is further analyzed and broken up into atomic components that form the basis for the classes that need to be designed.

4. (b)

Vidyala

nkar



However, besides use cases, the artifacts of a project, such as stakeholder requests, (signed off) requirement documents, functional specifications, and a glossary of terms for the project serve as other important inputs to the discovery of classes.

Essentials of UML class diagrams

The main symbols show on class diagrams are : • Classes, which represent the types of data themselves. • Associations, which represent linkages between classes. • Attributes, which are simple data found in classes and their instances. • Operations, which represent the functions performed by the classes and their instances. • Generalizations, which group classes into inheritance hierarchies. Quality To develop and deliver robust systems, we need a high level of confidence that • Each component will behave correctly. • Collective behavior is correct. • No incorrect collective behavior will be produced. Not only do we need to test components or the individual objects, we also must examine collective behaviors to ensure maximum operational reliability. Verifying components in isolation is necessary but not sufficient to meet this end. Quality Assurance Tests One reason why quality assurance is needed is because computers are infamous for doing what you tell them to do, not necessarily what you want them to do. To close this gap, the code must be free of errors or bugs that cause unexpected results, a process called debugging. Debugging is the process of finding out where something went wrong and correcting the code to eliminate the errors or bugs that cause unexpected results. For example, if an incorrect result was produced at the end of a long series of computations, perhaps you forgot to assign the correct value to a variable, chose the wrong operator, or used an incorrect formula. Testing and searching for bugs is a balance of science, art, and luck. Sometimes, the error is obvious: The bug shows its hideous head the first time you run the application. Other bugs are stealthy and might not surface until a method receives a certain value or until you take a closer look at the output and find out that the results are off by a factor of a certain fraction or the

5. (a)

Class Name

attribute Type* initialValue

operation (arg list) return type

Class Name



1 *

Class Name



Class Name



Class Name



1

1..*

Vidyala

nkar



middle initials in a list of names are wrong. There are no magic tricks to debugging; however, by selecting appropriate testing strategies and a sound test plan, you can locate the errors in your sys-tem and fix them using readily available debugging tools. A software debugging system can provide tools for finding errors in programs and correcting them. Let us take a look at the kinds of errors you might encounter when you run your program :

• Language (syntax) errors result from incorrectly constructed code, such as an incorrectly typed keyword or some necessary punctuation omitted. These are the easiest types of errors to detect; for the most part, you need no debugging tools to detect them. The very first time you run your program the system will report the existence of these errors.

• Run-time errors occur and are detected as the program is running, when a statement attempts an operation that is impossible to carry out. For example, if the program tries to access a nonexistent object (say, a file), a run-time error will occur.

• Logic errors occur when code does not perform the way you intended. The code might be syntactically valid and run without performing any invalid operations and yet produce incorrect results. Only by testing the code and analyzing the results can you verify that the code performs as intended. Logic errors also can produce run-time errors.

The elimination of the syntactical bug is the process of debugging, whereas the detection and elimination of the logical bug is the process of testing. As you might have experienced by now, logical errors are the hardest type of error to find. Quality assurance testing can be divided into two major categories: error-based testing and scenario-based testing. Error-based testing techniques search a given class's method for particular clues of interests, then describe how these clues should be tested. For example, say we want to test the payroll Computation method of an Employee class: anEmployee.computePayroll (hours). To test this method, we must try different values for hours (say, 40, 0, 100, and 10) to see if the program can handle them (this also is known as testing the boundary conditions). The method should be able to handle any value; if not, the error must be recorded and reported. Similarly, the technique can be used to perform integration testing by testing the object that processes a message and not the object that sends the message. Scenario-based testing, also called usage-based testing, concentrates on what the user does, not what the product does. This means capturing use cases and the tasks users perform, then performing them and their variants as tests. These scenarios also can identify interaction bugs. They often are more complex and realistic than error-based tests. Scenario-based tests tend to exercise multiple subsystems in a single test, because that is what users do. The tests will not find everything, but they will cover at least the higher visibility system interaction bugs. Testing Strategies The extent of testing a system is controlled by many factors, such as the risks involved, limitations on resources, and deadlines. In light of these issues, we must deploy a testing strategy that does the "best" job of finding defects in a product within the given constraints. There are many testing strategies, but most testing uses a combination of these: black box testing, white box testing, top-down testing, and bottom-up testing. However, no strategy or combination of strategies truly can prove the correctness of a system; it can establish only its "acceptability." Black Box Testing The concept of the black box is used to represent a system whose inside workings are not available for inspection. In a black box, the test item is treated as "black," since its logic is unknown; all that is known is what goes in and what comes out, or the input and output (see Figure (a)). Weinberg describes writing a user manual as an example of a black box approach to requirements. The user manual does not show the internal logic, because the users of the system do not care about what is inside the system.

5. (b)

Vidyala

nkar



Fig.(a): The black box is an imaginary box that hides its internal workings.

In black box testing, you try various inputs and examine the resulting output; you can learn what the box does but nothing about how this conversion is implemented. Black box testing works very nicely in testing objects in an object-oriented environment. The black box testing technique also can be used for scenario-based tests, where the system's inside may not be available for inspection but the input and output are defined through use cases or other analysis information. White Box Testing White box testing assumes that the specific logic's. important and must be tested to guarantee the system's proper functioning. The main use of the white box is in error-based testing, when you already have tested all objects of an application and all external or public methods of an object that you believe to be of greater importance (see Figure (b)). In white box testing, you are looking for bugs that have a low probability of execution, have been carelessly implemented, or were overlooked previously.

Fig.(b) : In a white-box testing strategy, the internal workings are known.

One form of white box testing, called path testing, makes certain that each path in a object's method is executed at least once during testing. Two types of path testing are statement testing coverage and branch testing coverage : Statement testing coverage. The main idea of statement testing coverage is to test every

statement in the object's method by executing it at least once. Murray states, "Testing less than this for new software is unconscionable and should be criminalized" [quoted in 2]. However, realistically, it is impossible to test a program on every single input, so you never can be sure that a program will not fail on some input.

Branch testing coverage. The main idea behind branch testing coverage is to perform enough tests to ensure that every branch alternative has been executed at least once under some test [3]. As in statement testing coverage, it is unfeasible to fully test any program of considerable size.

Most debugging tools are excellent in statement and branch testing coverage. White box testing is useful for error-based testing.

Vidyala

nkar



Top-Down Testing Top-down testing assumes that the main logic or object interactions and systems messages of the application need more testing than an individual object's methods or supporting logic. A top-down strategy can detect the serious design flaws early in the implementation.

In theory, top-down testing should find critical design errors early in the testing process and significantly improve the quality of the delivered software because of the iterative nature of the test. A top-down strategy supports testing the user interface and event-driven systems.

Testing the user interface using a top-down approach means testing interface navigation. This serves two purposes, according to Conger. First, the top-down approach can test the navigation through screens and verify that it matches the requirements. Second, users can see, at an early stage, how the final application will look and feel. This approach also is useful for scenario-based testing. Top-down testing is useful to test subsystem and system integration. Bottom-Up Testing Bottom-up testing starts with the details of the system and proceeds to higher levels by a progressive aggregation of details until they collectively fit the requirements for the system. This approach is more appropriate for testing the individual objects in a system. Here, you test each object, then combine them and test their interaction and the messages passed among objects by utilizing the top-down approach.

Fig.: Vertical strategies for incremental integration testing.

An inspection is an activity in which one or more people systematically examine source code or documentation, looking for defects. Normally, inspection involves a meeting, although participants can also inspect alone at their desks. Some general principles of inspecting are as follows : i) Inspect the most important documents of all types Inspection should be performed on code,

design documents, test planes and requirements. It is not always necessary or economical to inspect every single piece of code or every document but the most important ones should certainly be inspected. Quality will be higher if more are inspected but costs will also be higher.

ii) When inspecting code, all aspects of code should be considered including the comments.

iii) Choose an effective and efficient inspection team. Two or more people should participate in an inspection, since more pairs of eyes are better than one. However it is uneconomical to have a very large number of people involve, between two and five people (including the

6. (a) Vidyala

nkar



author) is probably a good range the exact number can depend on the importance of the item being inspected. The inspection team should include experienced software engineers who are more likely to uncover defects.

iv) Require that participants prepare for inspections. The inspection team should study the code or other documents prior to the meeting and come prepared with a list of defects. If a participant has not prepared, then he or she will spend most of his or her mental energy at the inspection meeting trying to understand the document, rather than helping to find defects.

v) Only inspect documents that are ready. Inspections should be held once specifications design documents or code are believed by their authors to be final. However, when prepring for an inspection meeting, the inspectors might immediately realize that the document represents very poor design, that its layout is messy and hard to read, or that it needs some other major change; in these circumstances it is probably best to call off the meeting. The author should be asked to make change before a new attempt is made at inspection. Attempting to inspect a very poor document will result in defects being missed-and the document will have to be re-inspected anyway.

vi) Have finding defects as the only goal. It is best not to mix inspection meetings with meetings in which other activities are involved. For example, if you are inspecting code, you should not at the same time be teaching newcomers how the system works. Having the secondary goal would detract from the primary goal, which is to find defect.

vii) Avoid discussing how to fix defects. Fixing defects is a design issue that can be left to the author. There is no need to consume the time of the entire team during the meeting. If the author needs help with a particular defect, he or she can always ask for it later.

viii)Avoid discussing style issues. It is important that inspections do not become bogged down debating such issues as the naming convention used for variables, or whether the ‘{’ and ‘}’ should always line up with each other vertically or not. Issues such as these may be important, but should be discussed separately, in the context of the project as a whole.

ix) Do not rush the inspection process. The schedule should be arranged so that there is time both to complete the necessary inspections and to fix, the defects found. A common problem is to be rushing to meet deadlines and hence to skip inspection or to fail to properly fix the defects found.

x) Avoid making participants tired. Since inspection is very mentally taxing, it is best not to inspect for more than two hours at a time, or for more than four hours a day.

xi) Keep and use logs of inspections. Logs of inspections should be kept. These will list what was inspected and the defects found. Follow-up should be done after every inspection session to ensure that all the defects have, in fact, been resolved.

xi) Re-inspect when changes are made. You should re-inspect any document or code that is changed more than 20% for any reason, for example, as a result of adding new features, or fixing problems arising from testing or inspection.

Introduction : A function model, also called an activity model or process model, is a graphical representation of an enterprise’s function within a defined scope. The purposes of the function model are to describe the functions and processes, assist with discovery of information needs, help identify opportunities, and establish a basis for determining product and service costs.

i) The functional model shows how values are computed, without regard for sequencing, decisions, or object structure.

ii) The functional model shows which values depend on which other values and the functions that relate them.

iii) Data flow diagrams are useful for showing functional dependencies.

6. (b) Vidyala

nkar



Start by sketching an outline of the architecture i) Based on the principal requirements and use cases. ii) Determine the main components that will be needed. iii) Choose among the various architectural patterns. Discussed next

Suggestion: have several different teams independently develop a first draft of the architecture and merge together the best ideas. Refine the architecture i) Identify the main ways in which the components will interact and the interfaces between

them ii) Decide how each piece of data and functionality will be distributed among the various

components. iii) Determine if you can re-use an existing framework, if you can build a framework. iv) Consider each use case and adjust the architecture to make it realizable. Mature the architecture Architectural Patterns The notion of patterns can be applied to software architecture. These are called architectural patterns or architectural styles. Each allows you to design flexible systems using components. The components are as independent of each other as possible. The recurring aspects of designs are called design patterns. i) A pattern is the outline of a reusable solution to a general problem encountered in a particular

context. ii) Many of them have been systematically documented for all software developers to use iii) A good pattern should

- Be as general as possible - Contain a solution that has been proven to effectively solve the problem in the indicated

context. - Studying patterns is an effective way to learn from the experience of others.

Pattern description (a) Context: The general situation in which the pattern applies. (b) Problem : A short sentence or two raising the main difficulty. (c) Forces: The issues or concerns to consider when solving the problem. (d) Solution : The recommended way to solve the problem in the given context.

- 'to balance the forces'

7. (a)

Cash Card

Account

User

read inputs perform

transaction generate outputs

bank code. card code balance

Messages. cash, receipt

password, transaction kind, amount, account type

Vidyala

nkar



(e) Antipatterns: (Optional) Solutions that are inferior or do not work in this context.

(f) Related patterns: (Optional) Patterns that are similar to this pattern.

(g) References: Who developed or inspired the pattern. Frameworks i) It is a reusable software that implements a generic solution to a generalized problem. ii) it provides common facilities applicable to different application programs. Key Principles i) Application that do different but related things tend to have similar designs. ii) The missing parts are often called slots. iii) The application developers fills in these slots in an application specific way to adapt the

framework to his or her needs. Hook i) Framework also use hook. ii) These are like slots, expect that they represent functionality that it is optional for the

developers to provide when they exploit the framework. Principles leading to good design : Applying the design principles diligently with result in designs that have many advantages over designs in which the principles were not applied. Some overall goals want to achieve when doing good design are: i) Increasing profit by reducing cost and increasing revenue. For most organizations, this is the

central objective. However, there are a number of ways to reduce cost, and also many different ways to increase the revenue generated by so ware.

ii) Ensuring that we actually conform with the requirements, thus solving the customer's problems.

iii) Accelerating development. This helps reduce short-term costs, helps ensure die software reaches the market soon enough to effectively complete, and may be essential to meet some deadline faced by the customer.

iv) Increasing qualities such as usability, efficiency, reliability, maintainability and reusability. These can help reduce costs and also increase revenues.

Design principle 1: Divide and conquer The divide and conquer principle dates back to the earliest days of organized human activity. Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things. In software engineering, the divide and conquer principle is applied in many ways. We have already seen how the process of development is divided into activities such as requirements gathering, design and testing. In this section we will look at how software systems themselves can be divided. Design principle 2 : Increase cohesion where possible The cohesion principle is an extension of the divide and conquer principle -divide and conquer simply says to divide things up into smaller chunks. Cohesion says to do it intelligently: yes, divide things up, but keep things together that belong together. A subsystem or module has high cohesion if it keeps together things that are related to each other, and keeps out other things. This makes the system as a whole easier to understand and change. Design principle 3: Keep the level of abstraction as high as possible You should ensure that your designs allow you to hide or defer consideration of details, thus reducing complexity. The general term given to this property of designs is abstraction, and a good abstraction is said to provide information hiding Abstractions are needed because the human brain can process only a limited amount of information at any on time.

7. (b)

Vidyala

nkar



Design principle 4: Increase reusability where possible There are two complementary principles that relate to reuse; the first is to increase reusability, and the second is to actively reuse the work of others. Designing for reusability means designing various aspects of your system so that they can be used again in other contexts, both in your system and in other systems. Mechanisms whereby components can be reused include calling procedures and inheriting a superclass. Design principle 5 : Reuse existing designs and code where possible Design with reuse is complementary to design for reusability. Actively reusing designs or code allows you to take advantage of the investment you or others have made in reusable components. Design principle 6 : Design for flexibility Designing for flexibility means actively anticipating changes that a design may have to undergo UP future and preparing for them. Such changes might include changes in implementation (e.g. to improve efficiency or to handle larger volumes of data) or changes in functional requirements. Design principle 7 : Anticipate obsolescence Anticipation of obsolescence is a special case of design for flexibility. Changes will inevitably occur in the technology a software system uses and in the environment in which it runs. Anticipating obsolescence means planning for changes in the technology or environment so the software will continue to run or can be easily changed. Design principle 8 : Design for portability Designing for portability shares many things in common with anticipating obsolescence, although the objective is different. Anticipating obsolescence has, as its primary objective, the survival of the software. Design for portability has, as its prime objective, the ability to have the software run on as many platforms as possible, although sometimes this might also be a necessity for survival. Design principle 9 : Design for testability During design you can take steps to make testing easier. Testing, which is the subject of the next chapter, can be performed both manually and automatically. Automatic testing involves writing a program that will provide various inputs to the system in order to test it thoroughly. Therefore it pays to design a system so automatic testing is made easy. Design principle 10: Design defensively You should never trust how others will try to use a component you are designing. Just like automobile drivers are taught not to trust other drivers, and so to drive defensively, a software designer should not trust other designers or programmers, and so should design defensively. In other words, in order to increase the reliability of your system, you not only need to make sure you don't add any defects yourself, but you must also properly handle all cases where other code attempts to use your component Appropriately.

Vidyala

nkar