August 2009 Master Of Science In Information Technology (mscit-new) –

August 2009 Master of Science in Information Technology (MScIT-NEW) – Semester 3 MT0047 –: Advance Software Engineering– 4Credits (Book ID: B0808 & B0809)

Assignment Set – 1 (60 Marks) Each question carries six marks

10 x 6 = 60

Book ID: B0808 1. Explain the different Software Applications Ans:- Systems Software is "Middleware" that runs the infrastructure that supports the application software. Most people never notice or interact with this software unless it breaks and then you get frustrated because you can't do your normal job or transaction. Application Software is the software that most end-users are familiar with and where the "work" is done by the average person, i.e. order entry, billing, data searching, etc.

2. What are the limitation of the linear sequential model? Ans:- Description: This is the most frequently used model. The development team

specifies the business functionality of the software prior to developing a system. It then breaks the complex mission of development into several logical steps, starting with requirements gathering and ending with release. The development process follows through analysis, design, coding, testing, and then support in a strictly linear fashion. Leads to a formal project management approach such as sign-off and one deliverableperphase. Limitations/Problems: Not robust to change. Does not aid in using information gathered after coding has begun,such as a better understanding of the requirements. Deliverable may not fully satisfy the customer

3. Explain Iterative Development Model in detail. Ans:- Software Planner is an award winning application lifecycle management (ALM) iterative development tool that helps Information Technology (IT) departments manage all components of software development including managing customer requirements, project deliverables, test cases, defects, and support tickets. Coupled with collaborative tools like document sharing, team calendars, interactive dashboards, knowledge bases and threaded discussions, teams begin communicating more effectively and begin delivering solutions quickly and with high quality. Software Planner is an award winning application lifecycle management (ALM) tool that helps Information Technology (IT) departments manage all components of software development including managing customer requirements, project deliverables, test cases, defects, and support tickets

4. What are the major technical and non technical factors which militate against widespread software reuse Ans:- Predicting the evolution of software engineering technology is, at best, a dubious proposition; most typically, it is a frustrating exercise in disappointment and anxiety. It is not difficult to see why: the evolution of software technology is fast paced, and is determined by a dizzying array of factors, many of them outside the arena of software engineering, and most of them cannot be identified, let alone predicted, with any significant advance notice. In this paper, we briefly discuss our first ventures in this domain, and some (very) preliminary conclusions and resolutions.

5.

What are advantage of software development with reuse

ans:- There’s a time for custom software development. And there’s a time for out-of-the-box

solutions. Knowing when to use each is critical for project success – and just happens to be something we excel at. Even when Itteco does custom development, we often use libraries of reusable code developed by us or other commercial or community organizations. If your project calls for a content management system, for example, we may use an existing one because there are so many good ones already. Using one instead of building one lets us focus on developing the more unique components of your project Software reuse keeps companies focused on their core development strengths and avoid wasting valuable project time on something that’s already been done. Software reuse lets us help our customers achieve their project goals in less time for less money. 2

Important advantages of software reuse include: • • • • •

Earlier time-to-market because the amount of coding required is reduced. High product quality because the development community extensively tests reusable code. Access to more current technologies because early adopters of cutting edge technology routinely make their reusable code available to the public. Faster turnaround times for software updates because quality reusable code typically requires fewer updates and fixes. Lower cost of ownership because reusable code reduces coding time.

How it works: 1. Gather requirements. We gather your project requirements, assess your individual business needs and record them for you in a Project Vision document. 2. Evaluate applications. We evaluate the best out-of-the-box software applications against your project requirements to narrow down the best candidates. 3. Create application comparison matrix. This step takes our reuse service to the next level. We create a comparison matrix of the best reusable applications to meet your project goals. That way, you can be fully confident that the reusable application you select is the best choice for your project, no question. If we believe your project can benefit from multiple out-of-the-box applications, we will let you know so you can make a fully informed decision. 4. Implement custom requirements. We implement any custom modifications to the application to ensure it meets the specific requirements of your project and provide any needed customized source code. 5. Deploy and maintain the application. When the selected out-of-the-box application has been modified to your project specifications, we deploy it and provide maintenance parameters to ensure it continues to serve your needs. Book ID: B0809 6. What are the advantages of Incremental Models? Ans:- There are many variations on this theme. One of the main advantages of the incremental

models is their ability to cope with change during the development of the system. As an example, consider an error in the requirements. With the waterfall model, the error may not be noticed until acceptance testing, when it is probably too late to correct it. (Note that the client probably does not see the software running until the acceptance tests.) In the incremental model, there is a good chance that a requirements error will be recognized as soon as the corresponding software is incorporated into the system. It is then not a big deal to correct it. The waterfall model relies on careful review of documents to avoid errors. Once a 3

phase has been completed, there is limited provision for stepping back. It is difficult to verify documents precisely and this is, again, a weakness of the waterfall model. There is a wide array of software development processes tagged as incremental models. They all take their origins in the above mentioned deficiency of the Waterfall model, i.e. its inability to cope with change. In incremental models, software is build not written. Software is constructed step by step in the same way a building is constructed. The products is designed, implemented, integrated and tested as a series of incremental builds, where a build consists of code pieces from various modules interacting together to provide a specific functional capability and testable as a whole. If the incremental model is broken in too few builds it is becoming a build and fix model. The requirements, specifications and architectural design must be completed before the implementation for the various builds commences. A typical product will consist of 10-50 builts. One of the main reasons why the Waterfall model is not appropriate in most cases is the accumulation of too much unstable information at all stages. For example, a complete list of 500 requirements is extremely likely to change, no matter how confident is the client on the quality of these requirements at this point. Inevitably, the further design and implementation phases will uncover flaws in these requirements, raising the need for the update and reverification of the requirements as a whole each time majors flaws are uncovered. A better approach is thus to limit the accumulation of unstable information by concentrating on the definition and implementation of only a subset of the requirements at a time. Such an approach has the benefit of distributing the feedback on the quality of the accumulated information. In the Waterfall model, most of the relevant feedback is received towards the end of the development cycle, where the programming is concentrated. By distributing the development efforts throughout the development cycle, incremental models also acheive distribution of feedback, thus increasing the stability of the accumulated artifacts. Advantages • • •

• • • •

Delivers an operational quality product at each stage, but one that satisfies only a subset of the clients requirements. A relative small number of programmers/developers may be used. From the delivery of the first build, the client is able to perform useful work (portions of the complete product might be available to customers in weeks instead of waiting for the final product, compared waterfall, rapid prototyping model, which deliver only then the complete product is finished). Reduces the traumatic effect of imposing a completely new product on the client organization by providing a gradual introduction. There is a working system at all times. Clients can see the system and provide feedback. Progress is visible, rather than being buried in documents.

4

•

•

Most importantly, it breaks down the problem into sub-problems, dealing with reduced complexity, and reduced the ripple effect of changes by reducing the scope to only a part of the problem at a time. Distributes feedback throughout the whole development cycle, leading to more stable artifacts

7. Write an overview on the Rational Unified Process. Ans:- During my employment at Page Technologies, I had the opportunity to introduce the

concept of the RUP® (the Rational Unified Process®) to a variety of individuals in a variety of scenarios across a variety of business domains. In some scenarios, I was in the role of project manager, in some I had a sales role, in others I was conducting a seminar. In each case, the challenge was how to effectively communicate the robust capabilities that the RUP offers. In a nutshell, I find that it's helpful to compare the RUP to a restaurant buffet. That's right. Before I explain, though, I'd like to suggest that you might find this analogy useful if your job involves trying to sell or introduce RUP to an organization. The buffet comparison is most helpful in communicating the basic concepts of RUP: the four phases, iterative development, tailoring RUP to meet the business need, and so on. You may find it useful if: 1. You are a project manager trying to convince your team members or management that your organization should adopt RUP. 2. You are part of a process group that wants the broader development organization to adopt RUP. 3. You are trying to change the opinion of an organization or individuals who think RUP is an inflexible monolith that can't compete with processes such as XP, RAD, etc. 4. You are trying to convey the value of RUP to an organization or individuals who think process is just a make-work effort geared at large artifact thwomp factors (i.e., how loud of a sound a document makes when it hits the desk). The goal for this article is not to provide ROI analysis or empirical data that will allow you to justify implementing RUP. Rather, it is to provide an analogy that will help your audience understand how RUP should be implemented. The Basic Analogy Let me start off by stating that I love buffets. I enjoy the periodic lunchtime jaunts to the local Chinese, Indian, Thai, and Mexican buffets that my development teams and I have taken over the past many years. It was after one of these forays to a local Minneapolis restaurant a few years ago that it occurred to me: The RUP is not unlike a visit to one of these buffets. You have requirements, and you have a potential solution. The requirements are driven by a need (hunger) and the solution (food) is provided by the buffet. How you deliver this solution to your stomach is the process. Chances are, if you are like me, that you will make several trips to 5

the buffet (iterations) and use several tools and activities to assemble different foods from different courses (phases). Table 1 details this analogy 8. Write the merits & demerits of proto type model Ans:- Prototype is a model that can explain the structure of the functions we are going to use in our C and C++ programs.Suppose we are going to use one function called add with two parameters to add means the prototype of the function is int add(int a,int b), simply prototype in C and C++ is the function declaration Prototype is a model that can explain the structure of the functions we are going to use in our C and C++ programs.Suppose we are going to use one function called add with two parameters to add means the prototype of the function is int add(int a,int b), simply prototype in C and C++ is the function declaration prototype of the function tell the compiler that this type of function is defined in the program The word prototype comes from the Latin words proto, meaning original, and typus, meaning form or model. In a non-technical context, a prototype is an especially representative example of a given category. In prototype-based programming, a prototype is an original object; new objects are created by copying the prototype.

9. Explain the round-trip problem solving approach. Ans:- The round trip theorem is used to send the output of an inverse function back to the input it came from, hence the name round trip. The book has a pretty good explanation of it. It basicalls says that: g(f(y))=y and f(g(x))=x for y in the domain of f and all x in the domain of g It is just a way of determining if 2 functions are inverses. Question to 3R, #57: What is the order or transformations. I thought you could stretch vertically by 3, translate 7 units right, reflect over the x-axis, and translate 2 units up. The book got something different. Can someone explain to me the order of transformations?

6

10. Explain various phases of software development life cycle Ans:- Summary: As in any other engineering discipline, software engineering also has

some structured models for software development. This document will provide you with a generic overview about different software development methodologies adopted by contemporary software firms. Read on to know more about the Software Development Life Cycle (SDLC) in detail.Like any other set of engineering products, software products are also oriented towards the customer. It is either market driven or it drives the market. Customer Satisfaction was the buzzword of the 80's. Customer Delight is today's buzzword and Customer Ecstasy is the buzzword of the new millennium. Products that are not customer or user friendly have no place in the market although they are engineered using the best technology. The interface of the product is as crucial as the internal technology of the product

A market study is made to identify a potential customer's need. This process is also known as market research. Here, the already existing need and the possible and potential needs that are available in a segment of the society are studied carefully. The market study is done based on a lot of assumptions. Assumptions are the crucial factors in the development or inception of a product's development. Unrealistic assumptions can cause a nosedive in the entire venture. Though assumptions are abstract, there should be a move to develop tangible assumptions to come up with a successful product. Once the Market Research is carried out, the customer's need is given to the Research & Development division (R&D) to conceptualize a cost-effective system that could potentially solve the customer's needs in a manner that is better than the one adopted by the competitors at present. Once the conceptual system is developed and tested in a hypothetical environment, the development team takes control of it. The development team adopts one of the software development methodologies that is given below, develops the proposed system, and gives it to the customer.

7

August 2009 Master of Science in Information Technology (MScIT-NEW) – Semester 3 MT0047 –: Advance Software Engineering– 4Credits (Book ID: B0808 & B0809)

Assignment Set – 2 (60 Marks) Each question carries six marks

10 x 6 = 60

Book ID: B0808 1. Explain Iterative Development Model in detail.

Ans:- The basic idea behind iterative enhancement is to develop a software system incrementally, allowing the developer to take advantage of what was being learned during the development of earlier, incremental, deliverable versions of the system. Learning comes from both the development and use of the system, where possible. Key steps in the process were to start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving sequence of versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The Procedure itself consists of the Initialization step, the Iteration step, and the Project Control List. The initialization step creates a base version of the system. The goal for this initial implementation is to create a product to which the user can react. It should offer a sampling of the key aspects of the problem and provide a solution that is simple enough to understand and implement easily. To guide the iteration process, a project control list is created that contains a record of all tasks that need to be performed. It includes such items as new features to be implemented and areas of redesign of the existing solution. The control list is constantly being revised as a result of the analysis phase. The iteration involves the redesign and implementation of a task from the project control list, and the analysis of the current version of the system. The goal for the design and implementation of any iteration is to be simple, straightforward, and modular, supporting redesign at that stage or as a task added to the project control list. The level of design detail is not dictated by the interactive approach. In a light-weight iterative project the code may represent the major source of documentation of the system; however, in a missioncritical iterative project a formal Software Design Document may be used. The analysis of an iteration is based upon user feedback, and the program analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, & achievement of goals. The project control list is modified in light of the analysis results. Iterative development slices the deliverable business value (system functionality) into

8

iterations. In each iteration a slice of functionality is delivered through cross-discipline work, starting from the model/requirements through to the testing/deployment. The unified process groups iterations into phases: inception, elaboration, construction, and transition. Inception identifies project scope, risks, and requirements (functional and non-functional) at a high level but in enough detail that work can be estimated. Elaboration delivers a working architecture that mitigates the top risks and fulfills the nonfunctional requirements. Construction incrementally fills-in the architecture with production-ready code produced from analysis, design, implementation, and testing of the functional requirements. Transition delivers the system into the production operating environment.

Each of the phases may be divided into 1 or more iterations, which are usually time-boxed rather than feature-boxed. Architects and analysts work one iteration ahead of developers and testers to keep their work-product backlog full. 2. Mention the characteristics of object oriented design. Ans:- Department of Information and Systems Management, The Hong Kong University of

Science and Technology, Clear Water Bay, Kowloon, Hong Kong, People's Republic of China b

Delta Banka AD, Belgrade, Yugoslavia

Received 11 November 1996; revised 27 January 1997; accepted 10 March 1997. Available online 19 January 1999.

Abstract The metrication of object-oriented software systems is still an underdeveloped part within the domain of the object paradigm. An empirical investigation aimed at finding appropriate measures and establishing simple, yet usable and cost-effective models for estimation and control of object-oriented system projects, was undertaken on a set of object-oriented projects implemented in a stable environment. First, the measures available were screened for possible correlations; then, the models suitable for 9

estimation were derived and discussed. Effort was found to correlate well with the total number of classes and the total number of methods, both of which are known at the end of the design phase. A number of other models for estimation of the source code complexity were also defined. Author Keywords: Software measurement; Software estimation; Object-oriented software 3. What is software reengineering? Explain Ans:- The reengineering of was described by Chikofsky and Cross in their 1990 paper, as "The examination and alteration of a system to reconstitute it in a new form". Less formally, reengineering is the modification of a software system that takes place after it has been reverse engineered, generally to add new functionality, or to correct errors. This entire process is often erroneously referred to as; however, it is more accurate to say that reverse engineering is the initial examination of the system, and reengineering is the subsequent modification. 4. Explain parallel or concurrent development Model.

Ans:- The Dual Vee Model, like the V-Model is a systems development model designed to simplify the understanding of the complexity associated with developing systems.[1][2][3] In systems engineering it is used to define a uniform procedure for product or project development. The model addresses the necessary concurrent development of a system’s architecture with the entities of that architecture and illuminates the necessary interactions and sequences recommended for orderly maturation of a system and systems of systems. This article explains the power of the Dual Vee Model when applied as a reminder model for development of complex systems, Thomas Kuhn observed in his noteworthy The Structure of Scientific Revolution[4] "The power of science seems quite generally to increase with the number of symbolic generalizations its practitioners have at their disposal." Models simplify our life by clarifying the complex and by explaining the difficult to understand. They also facilitate our explaining to others the principles we hold dear. In systems engineering we model just about everything. We routinely make user requirements understanding models, technical feasibility models, physical fit models, and we model complex operational scenarios to gain the required comprehension and we then hone the models to achieve even better solutions. When systems engineers develop systems they frequently rely on current models to guide their way. However, the most prevalent models, waterfall, spiral, and Vee have not been

10

sufficiently explicit regarding the concurrent development of the system architecture and the entities of the same system. A software development method defined by Dr. Winston W. Royce in 1969 to promote a sequentially phased software development process. The model promotes knowing the requirements before designing and designing before coding, etc. The objective was to provide a repeatable process to the then undisciplined (generally ad hoc) software development environment. While the model is accurate for what is depicted it is silent on user involvement, risk management, and most importantly, it is a single solution model that fails to address architecture development that is inherent in all multiple entity systems. Although designed for software, the model can be applied to hardware and system development. Spiral Model[6] -- A software development method defined by Dr. Barry Boehm in 1980 to promote the management of recognized risks prior to attempting traditional phased software development. The model promotes resolving requirements, feasibility, and operational risks prior to proceeding with the traditional waterfall phases. The objective is to involve users and stakeholders in resolving recognized software development issues preceding concept development and design. This model is accurate for what is depicted but it also fails to address the problems of architecture development and management. Although designed for software the spiral model can also be applied to hardware and system development. Vee Model[7][8][9][10][11] -- A system development method defined and elaborated by Dr. Kevin Forsberg and Hal Mooz from 1987 to 2005 to address system development issues of decomposition, definition, integration, and verification. The model also includes user/stakeholder participation, concurrent opportunity and risk management, and verification problem resolution

5. Explain white box and black box model. Ans:- A white-box framework requires the framework user to understand the internals of the

framework to use it effectively. In a white box framework, you usually extend behavior by creating subclasses, taking advantage of inheritance. A white box framework often comes with source code. A black-box framework does not require a deep understanding of the framework’s implementation in order to use it. Behavior is extended by composing objects together, and delegating behavior between objects. A framework can be both white-box and black-box at the same time. Your perception of how “transparent” a framework is may depend on non-code aspects such as documentation or tools. Frameworks tend to change over their lifetime. (See [Johnson & Roberts].) When a framework is new, it tends to be white-box: you change things by subclassing, and you have to peak at source code to get things done. As it evolves, it becomes more black-box, and you find yourself 11

composing structures of smaller objects. Johnson and Roberts point out that frameworks can evolve beyond black-box, perhaps becoming visual programming environments, where programs can be created by interconnecting components selected from a palette. (JavaBeans is an effort in that direction.) Visual environments and even black-box frameworks sound so much easier to use than whitebox frameworks - why would we ever bother creating white-box frameworks in the first place? The basic answer is “cost”. To develop a black-box framework, we need a sense of which objects change the most, so we can know where the flexibility is most needed. To develop a visual environment, we need even more information: we need to know how objects are typically connected together. Discovering this costs time. White-box frameworks are easier to create and have more flexibility.

White-Box Frameworks The most common sign that a framework is white-box is heavy use of inheritance. When you use the framework by extending a number of abstract (or even concrete) classes, you are dealing with a white-box framework. Inheritance is a closer coupling than composition; an inherited class has more context it must be aware of and maintain. This is visible even in Java’s protection scheme: a subclass has access to the public and protected parts of the class, while a separate object only sees the public parts. Furthermore, a subclass can potentially “break” a superclass even in methods it doesn’t override, for example by changing a protected field in an unexpected way. What are the effects of an inheritance-based approach? • • We need to understand how the subclass and superclass work together. • • We have access to both the protected and the public parts of the class. • • To provide functionality, we can override existing methods, and implement abstract methods. • • We have access to the parent’s methods (by calling super.method()). Example: A simple applet import … public class MyApplet extends Applet { public void paint(…) {…} //TBD?? } Notice how we depend directly on the superclass, even to using its methods freely. A subclass is coupled to its parents, and we deal with the benefits and costs of that fact.

12

Black-Box Frameworks Black-box frameworks are based on composition and delegation rather than inheritance. Delegation is the idea that instead of an object doing something itself, it gives another object the task. When you delegate, the object you delegate to has a protocol or interface it supports, that the main object can rely on. In black-box frameworks, objects tend to be smaller, and there tend to be more of them. The intelligence of the system comes as much from how these objects are connected together as much as what they do in themselves. Composition tends to be more flexible than inheritance. Consider an object that uses inheritance versus one that delegates. With inheritance, the object basically has two choices: it can do the work itself, or it can call on the parent class to do it. In a language like Java, the parent class is fixed at compile time. With delegation, an object can do the work itself (or perhaps in its parent), or it can give the work to another object. This object can be of any useful class (rather than only the parent), but it can also change over time. (You can delegate to an object, change the delegate to be another object, and use the new object as the delegate next time.) Example: TBD [TBD compare to cutting grass - children vs. lawn service?]

Converting Inheritance to Composition In “Designing Reusable Classes,” Johnson and Foote identify this rule: Rule 12. Send messages to components instead of to self. An inheritance-based framework can be converted into a component-based framework black box structure by replacing over-ridden methods by message sends to components. Let’s apply their advice to an example. Suppose we’ve got a class that sues the Template Method design pattern like this: public class ListProcessor { final public void processList() { doSetup(); while (hasMore()) { doProcess1(); } doTeardown(); }

13

protected void doSetup() {} protected void doTeardown() {} abstract protected boolean hasMore(); abstract protected void doProcess1(); // … }

with this as a typical subclass: public class TestProcessor extends ListProcessor { int i = 0; protected boolean hasMore() {return i < 5;} protected void doProcess1() {System.out.println(i);} }

In the simplest form of the transformation, we can take each method designed to be subclassed, and whenever it is called, replace it by a message to the delegate. We’ll also add some code to set up the delegate. public class ListProcessor { ListProcessor delegate; public ListProcessor(lp) {delegate = lp;} final public void processList() { delegate.doSetup(); while (delegate.hasMore()) { delegate.doProcess1(); } delegate.doTeardown(); } protected void doSetup() {} protected void doTeardown() {} abstract protected boolean hasMore(); abstract protected void doProcess1(); // … }

14

We can extend this like before. [TBD] You might create it like this: ListProcessor lp = new ListProcessor (new TestProcessor()); Compare how these two situations look at run-time: [LP] ß [Test] => [LP]odelegate

=>

[:Test]

[:LP] --- [:Test]

^ [Test] So far, this doesn’t seem to be worth the trouble: ListProcessor already has a copy of “processList()”; it doesn’t need the one in Test. The next step is to introduce a new class for the delegate, restricted to just the capabilities it needs. The methods called on the delegate define its protocol. We could handle this via an abstract class, but I prefer to use a Java interface: public interface ListProcessAction { void doSetup(); boolean hasMore(); void doProcess1(); void doTeardown(); }

These are the methods intended to be over-ridden. Now the main class can use the ListProcessorAction for its delegate. Furthermore, as ListProcessor is no longer intended to be subclassed, it no longer has any need for those protected methods: We could make our class depend on this interface: public class ListProcessor implements ListProcessorAction { ListProcessorAction delegate; public ListProcessor(ListProcessorAction a) {delegate = a;} final public void processList() { delegate.doSetup(); while (delegate.hasMore()) { delegate.doProcess1(); }

15

delegate.doTeardown(); } // … }

with this concrete implementation of the action: public class ConcreteAction { int i = 5; public void doSetup() {} public boolean hasMore() {return i < 5;} public void doProcess1() {System.out.println(i);} public void doTeardown() {} }

[TBD: Typically when these involve abstract methods, you might create an abstract class version, which will be extended by the end class. Or if the protocol is small and completely abstract, you don’t need concrete classes.] The structure looks like this: [LP] -delegate- [<> LPA] ^ [ConcreteAction]

=> [:LP] -delegate- [:CA]

This runtime structure is similar to the previous one, but now ListProcessor and ConcreteAction are separate classes. We have split one big object, that knew both the algorithm and the individual steps, into two classes, one for each concern. Look at the tradeoffs. In the initial version, everything was in one place. To trace the new version, you have to understand the delegation structure and how it can vary at runtime. When you write a new action, it’s easier to focus on it in isolation, but harder to see how it fits into the big picture. See how the design has changed: [TBD]

16

delega te

Lis tP roc es s or

Lis tP roc es s or

< < interfac e> > Lis tP roc es s orA c tion

bec om es

Y ourLis tP roc es s or Y ou rLis tP roc es s orA c t ion

[//TBD]

Step by Step This is a systematic description of how to convert [Base] to [Base] –delegate-- [<>Action] <- [ConcreteAction] Cautions: [TBD] • • Calls to super(). (Need to work through ramifications.) • • Recursion. (Need to eliminate or understand.) This approach follows a re-factoring style, moving in small steps and letting the compiler do the work. (See [Fowler].) 1.

1.

Create a new interface. public interface Action { } (name it appropriately). 2.

2.

3.

3. In Base, add a delegate field, and modify each constructor to take an Action as a parameter; use this to set the delegate: protected Action delegate;

Create a new class implementing this interface: public class ConcreteAction implements Action {}

public Base (Action a) { delegate = a; // rest as before } … 4. •

4. Each protected method in Base is presumably called in Base. For each such method: • Move the signature to Action and change it to “public” 17

• •

• •

Move the routine itself to ConcreteAction (and make it public there as well). Replace each call to “method()” with “delegate.method()”.

For example, Base {… protected method() { /*impl*/.} … method(); … } becomes Base {… delegate.method(); … } Action { … public method(); …} ConcreteAction {… public method() {/*impl*/} … } Note: You can find the call sites by temporarily changing the method name to “xxx”, and seeing what breaks in base. Moving protected methods may force you to pull over some private methods as well, or perhaps maintain a reference back to Base. Unfortunately, this is not a fully mechanical process. Similarly, if Base’s methods involve recursion or calls to super(), you will need insight into how the class works and how you want to split it. 5. • • •

5. Check whether methods in Base call any of Base’s public methods. If so, • Copy the signature to Action • Copy the method to ConcreteAction • Replace the method body in Base with “delegate.method()”.

Again, be aware of private methods, recursion, and super(). 6.

6.

Polish things up: get Base, Action, and ConcreteAction to compile properly.

7.

7. Check out any subclasses of Base. Figure out whether they should remain a subclass of Base, become a subclass of ConcreteAction, or become an independent action implementing the Action interface. (The class may need to be split.) Distribute the subclass’ behavior where it should go. As usual, be careful about recursion and super().

8.

8. Find each call to a constructor for Base or its subclasses. (Let the compiler tell you where they are.) Add a new parameter to the constructor, “new ConcreteAction()” where Base wants it.

18

Conflicting Class Hierarchies Java only supports single inheritance, but sometimes you find yourself wanting multiple inheritance. You can use interfaces and delegation to help in many such situations. Look at java.util.Observable. In some ways, it could be a basis for an implementation of the Observer design pattern. However, the fact that it is a class and not an interface is a flaw. Suppose you have a Vector, and you’d like it be Observable (perhaps so a listbox widget can watch it for changes). Because both Vector and Observable classes are already classes, you’d like this: [Vector] <- ObservableVector -> [Observable] // MI => !Java Suppose Observable were an interface instead. A class can implement as many interfaces as it needs to, so we could do this: [Vector] <- ObservableVector - - - > [<> Observable] // Legal Java but not JDK 1.x [TBD - double-check against JDK] There’s a reason Observable is a class though: it maintains machinery for notification. If we had a convenience implementation, we could delegate to it. [Vector] <- ObservableVector -- -- > [<> Observable] -- delegate -- [ObservableHelper] If Java had multiple inheritance, one class could cover both the Vector behavior and the Observable behavior. Without multiple inheritance, we can get the effect by connecting together a pair of classes. [TBD: How class can we get to the 1.1 Listener event model?] The Swing library designers faced this problem. Their solution is to ignore Observable, and instead create a ListModel that models the basics of vector handling. In Swing, there is an AbstractListModel, that handles notification, and can delegate to a concrete vector or list class.

Inner Classes for Multiple Inheritance Sometimes a class implements several interfaces when it would be better served by using Java's inner classes. Consider this example: public class MyPanel extends JPanel implements MouseListener { JButton b1 = new JButton("First"); 19

JButton b2 = new JButton("Second"); public MyPanel() { b1.addActionListener(this); add(b1); b2.addActionListener(this); add(b2); } public void actionPerformed(ActionEvent e) { if (e.getSource() == b1) { System.out.println("b1 action"); } else { // assume b2 System.out.println("b2 action"); } } } Here, MyPanel acts both like a JPanel and an listener. Notice the code for actionPerformed(): it’s got an ugly “if” statement that’s practically a case statement. Such a construct is a sign that we’re not as OO as we could be, and we can move intelligence around. We’ll use a pair of inner classes, cleaning up MyPanel a bit. This keeps it from receiving unnecessary notifications, and avoids the need for a test to see which button was clicked. public class MyPanel extends JPanel implements MouseListener { JButton b1 = new JButton("First"); JButton b2 = new JButton("Second"); public class FirstListener implements ActionListener { public void actionPerformed(ActionEvent e) { System.out.println(“b1”+e); } } public class SecondListener implements ActionListener { public void actionPerformed(ActionEvent e) { System.out.println(“b2” + Date.getTime()); } } public MyPanel() { b1.addActionListener(new FirstListener()); add(b1); 20

b2.addActionListener(new SecondListener()); add(b2); } } The first version was more in the style of JDK 1.0.2, where the event detection hierarchy had to match the container hierarchy. The second version is more in JDK 1.1 style. You can carry this a step further to use anonymous inner classes: public class MyPanel extends JPanel implements MouseListener { JButton b1 = new JButton("First"); JButton b2 = new JButton("Second"); public MyPanel() { b1.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(“b1”+e); } }); add(b1); b2.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(“b2” + Date.getTime()); } }); add(b2); } } Many people might find this on the edge of readability - some on the near side and some on the far side. “Rule 6. The top of the class hierarchy should be abstract.” Book ID: B0809

6. What are the various strategies for organizing the process of software development in an organization Ans:- This workshop is designed for IS professionals at all levels of experience who desire an understanding of how to define, collect, analyze and present a variety of software measurement information. It is appropriate for those organizations that wish to establish a

21

measurement program or enhance an existing one. The workshop focuses on the definition of software measures and providing guidelines for analysis, interpretation and presentation. The workshop will provide participants with the methods and techniques to define, analyze and report the appropriate measurement data to various audiences ranging from project staff to senior management. The workshop approach will allow the participants to develop usable measurement reports based on actual data collected in your organization Course Topics The following topics are addressed by this training: • • • • • • • •

The Uses and Benefits of Measurement Evaluating Measurement Requirements Data Sources and Collection Points Roles and Responsibilities Metrics Definition Data Analysis Measurement Reporting Identifying Improvement Opportunities

This course is designed for all professionals who have a need to effectively estimate effort, schedule and cost for software projects. The course is built on the understanding that the most successful estimating is based on accurately quantifying customer requirements using software measurement techniques. This includes potential scope creep, understanding project attributes and, most important, the size of the product to be delivered. Software size is the one factor that has the greatest impact on estimates. Function Point Analysis is now recognized as the best method to size software deliverables. Function Point Analysis is a proven, reliable method for measuring software development workproducts. The resulting work-product is expressed in terms of functionality as seen from the customer's perspective. Therefore, Function Point Analysis is extremely useful in communicating customer needs as well as estimating projects, measuring productivity and managing change of scope. This course demonstrates how Function Point Analysis techniques, in conjunction with reliable and repeatable estimating methods, provide an effective approach to predict project and application performance. This course focuses on leveraging Function Point information to forecast performance, while highlighting specific opportunities that can increase efficiency and effectiveness. Course Topics The following topics are addressed: •

Introduction to Estimating

22

Benefits and Uses The Fundamentals of Estimating with Function Points Overview of the Process Software Estimation Models and Techniques Understanding Function Point Based Productivity Rates Using Productivity Rates to Estimate Effort Estimating Cost and Schedule Understanding Influencing Attributes on Projects Adjusting Estimates Based on Attributes Documenting and Communicating the Estimate Implement Estimating Techniques 7. What are the main characteristics of successful teams? • • • • • • • • • • •

Ans:- Team goals are derived from critical farm problems that influence whether the business will exist in ten or twenty years such as the following: • • • • • • • •

30 percent increase in milk sales. Change in management styles from stall barn to milking parlors. Sale or transfer of the business. Arranging a new partnership for the business. Specialization in milk production only. New ventures. Managing non-family labor. Addressing complex unresolved management problems.

Teams should avoid farm problems that don't require the skills, experience, and judgment of off-farm advisers. This is a misuse of valuable resources and will eventually lead to dissatisfaction and dissolution of the advisory team. Team members and team problems should be well matched. As the team sets new goals, the composition of the team should be re-evaluated. Having a crop consultant or veterinarian on an intergenerational farm transfer team is likely to underutilize the crop consultant or veterinarian's abilities. An estate planner or attorney might be a better choice. Outstanding team members should have unique skills, experiences, and judgment not resident on the farm staff. They should also be team players and believe in the team process. Team members that have cross-purposes or hidden agendas can destroy a team's effectiveness and will have to be removed from the team. A team meeting is not a committee meeting but a highly creative process that benefits from locations that foster thinking and orderly discussion. Teams should meet in an environment similar to a boardroom, comfortable and away from interruptions and distractions

23

Complex problems rarely have simple solutions. Using processes for making decisions can clarify solutions, but solutions often need refinement over time. By frequently tracking progress toward goals and using measuring techniques, the team can monitor the degree of success and evaluate when to intercede. Also, the monitoring process helps advisers see progress and assess their time commitment. Without a measured benefit advisers cannot continue to justify their commitment as team members. 8. What are the various types of prototyping models? Ans:- Software prototyping, an activity during certain software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed.

A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation. The conventional purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. Prototyping can also be used by end users to describe and prove requirements that developers have not considered, so "controlling the prototype" can be a key factor in the commercial relationship between solution providers and their clients. Prototyping has several benefits: The software designer and implementer can obtain feedback from the users early in the project. The client and the contractor can compare if the software made matches the software specification, according to which the software program is built. It also allows the software engineer some insight into the accuracy of initial project estimates and whether the deadlines and milestones proposed can be successfully met. The degree of completeness and the techniques used in the prototyping have been in development and debate since its proposal in the early 1970s.[6] This process is in contrast with the 1960s and 1970s monolithic development cycle of building the entire program first and then working out any inconsistencies between design and implementation, which led to higher software costs and poor estimates of time and cost. The monolithic approach has been dubbed the "Slaying the (software) Dragon" technique, since it assumes that the software designer and developer is a single hero who has to slay the entire dragon alone. Prototyping can also avoid the great expense and difficulty of changing a finished software product.

Also called close ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the final delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system. 24

Rapid Prototyping involved creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can reexamine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements.[7] The most obvious reason for using Throwaway Prototyping is that it can be done quickly. If the users can get quick feedback on their requirements, they may be able to refine them early in the development of the software. Making changes early in the development lifecycle is extremely cost effective since there is nothing at that point to redo. If a project is changed after a considerable work has been done then small changes could require large efforts to implement since software systems have many dependencies. Speed is crucial in implementing a throwaway prototype, since with a limited budget of time and money little can be expended on a prototype that will be discarded. Another strength of Throwaway Prototyping is its ability to construct interfaces that the users can test. The user interface is what the user sees as the system, and by seeing it in front of them, it is much easier to grasp how the system will work. …it is asserted that revolutionary rapid prototyping is a more effective manner in which to deal with user requirements-related issues, and therefore a greater enhancement to software productivity overall. Requirements can be identified, simulated, and tested far more quickly and cheaply when issues of evolvability, maintainability, and software structure are ignored. This, in turn, leads to the accurate specification of requirements, and the subsequent construction of a valid and usable system from the user's perspective via conventional software development models. [8] Prototypes can be classified according to the fidelity with which they resemble the actual product in terms of appearance, interaction and timing. One method of creating a low fidelity Throwaway Prototype is Paper Prototyping. The prototype is implemented using paper and pencil, and thus mimics the function of the actual product, but does not look at all like it. Another method to easily build high fidelity Throwaway Prototypes is to use a GUI Builder and create a click dummy, a prototype that looks like the goal system, but does not provide any functionality. Not exactly the same as Throwaway Prototyping, but certainly in the same family, is the usage of storyboards, animatics or drawings. These are non-functional implementations but show how the system will look. SUMMARY:-In this approach the prototype is constructed with the idea that it will be discarded and the final system will be built from scratch. The steps in this approach are:

25

9. What are the essential best-practices which are followed in the rational unified process? Ans:- The IBM Rational Unified Process® (RUP®) is a complete software-development process framework that comes with several out-of-the-box instances. Processes derived from RUP vary from lightweight addressing the needs of small projects with short product cycles—to more comprehensive processes addressing the broader needs of large, possibly distributed project teams. Projects of all types and sizes have successfully used RUP. This white paper describes how to apply RUP in a lightweight manner to small projects. We describe how to effectively apply extreme Programming (XP) techniques within the broader context of a complete project.

Inception Inception is significant for new development efforts, where you must address important business and requirement risks before the project can proceed. For projects focused on enhancements to an existing system, the Inception phase is shorter, but is still focused on ensuring that the project is both worth doing and possible. During Inception, you make the business case for building the software. The Vision is a key artifact produced during Inception. It is a high-level description of the system. It tells everyone what the system is, and may also tell who will use it, why it will be used, what features must be present and what constraints 1 XP defines three phases: Exploration, Commitment, and Steering. These do not map well to RUP phases so we choose to use the four RUP phases to describe the process exist. The Vision may be very short, perhaps only a paragraph or two. Often the Vision contains the critical features the software must provide to the customer. Four essential Inception activities specified in RUP are: • Formulate the scope of the project. • Plan and prepare the business case. • Synthesize candidate architecture. • Prepare the project environment. Elaboration

26

The goal of the Elaboration phase is to baseline the architecture of the system to provide a stable basis for the bulk of the design and implementation effort in the Construction phase. The architecture evolves out of a consideration of the most significant requirements (those that have a great impact on the architecture of the system) and an assessment of risk. The stability of the architecture is evaluated through one or more architectural prototypes. In RUP, design activities focus on the notion of system architecture and, for softwareintensive systems, software architecture. Using component architectures is one of the six best practices of software development embodied in RUP, which recommends spending time developing and maintaining the architecture. The time spent on this effort mitigates the risks associated with a brittle and inflexible system. XP replaces the notion of architecture by “metaphor.” The metaphor captures part of the architecture, whereas the rest of the architecture evolves as a natural result of code development. XP assumes that architecture emerges from producing the simplest design and continually refactoring the code. On any project, you should do at least these three activities during Elaboration: • Define, validate, and baseline the architecture • Refine the Vision. • Create and baseline iteration plans for the Construction phase. Construction The goal of Construction is to complete the development of the system. The Construction phase is, in some sense, a manufacturing process, where you emphasize managing resources and controlling operations to optimize costs, schedules, and quality. In this sense, the management mindset undergoes a transition from the development of intellectual property during Inception and Elaboration, to the development of deployable products during Construction and Transition. Each Construction iteration has three essential activities: • Manage resources and control process. • Develop and test components. • Assess the iteration. Transition The focus of Transition is to ensure that software is available for its end users. The Transition phase includes testing the product in preparation for release and making minor

27

adjustments based on user feedback. At this point in the lifecycle, user feedback needs to focus mainly on fine-tuning the product, configuring, installing, and usability issues. The essential Transition activities are the following: • Finalize end-user support material. • Test the product deliverable in a customer environment. • Fine tune the product based upon customer feedback. • Deliver the final product to the end user. You can produce several artifacts during the Transition phase. If your product is one that will have future releases (and how many do not?), you will have begun identifying features and defect fixes for the next release. The essential artifacts for any project are: • Deployment Plan • Release Notes • Training Materials and Documentation. Digest Building software is more than writing code. A software development process must focus on all activities necessary to deliver quality to your customers. A complete process does not have to be heavy. We have shown how you can have a small, yet complete, process by focusing on the essential activities and artifacts for your project. Perform an activity or produce an artifact if it helps mitigate risk on your project. Use as much, or as little, process and formality as you need for your project team and your organization. RUP and XP are not necessarily exclusive. By incorporating techniques from both methods, you can arrive at a process that helps you deliver better quality software quicker than you do today. Robert Martin describes a process called the dX process, which he claims to be RUP compliant.8 It is an instance of a process built from the RUP framework

10. What are the advantages of the rapid application development model? Ans:- The practice of rapid application development was developed by James Martin in the year 1991. It is a frequently adopted method in development of high end software. The aim of the process is to develop a complete software solution within as less time as possible. It makes use of various structural procedures, (Computer Assisted Software Engineering tools) CASE tools and prototyping for describing processes to increase the

28

pace at which a software is developed. If a company is developing a graphical interface for a gaming software, rapid software development tools would facilitate speedy development of codes by integrating all the basic parameters in the prototype tools. A developer would simply use the tools, instead of writing a separate section of codes for that procedure. Sometimes, some features of a program are compromised in order to generate the end product in less time. An astounding 65% of the budget of large firms is spent on maintenance and upgrading its operating systems. These were designed only a certain time back, but given the nature of changes and their frequency, many softwares require changes. Quite often, the end users can satisfactorily meet all their requirements even without some essential components of a software. It is the task of a software developing team to identify all such potential areas of operation which can be left out or encapsulated within a broader heading, to save the time, effort and cost. In some other cases, the business which has ordered the software can negotiate on certain parts which can be done away with, before the software is fully developed. It may again save valuable cost and time before implementing the software. RAD is a combination of entities like a well-defined methodology, a dedicated and trained staff, proper and efficient management practices, and using both efficient manual and computer tools. The entire system of operation can be summarized as software development mechanism providing higher quality in less time using • • • •

Software essentials restructuring Prototyping and verification designs Integrating all changes in the current model Minimizing the effort of reviewing, testing and other such steps

Advantages of using RAD There are many advantages of using RAD and it can solve many concerns of the user as well as the developers. •

•

• •

Conventional software development methods take, on an average almost 20% more time than the RAD procedure. Using RAD can enable quicker visualization of the end-design and hence allow rapid software testing and rectifying steps. The customer is able to have a faster look at the design to add valuable inputs, in order to make the design more user-friendly. The current competitive scenario demands frequently upgraded softwares in order to effectively satisfy customers' requirements. RAD enables a faster and updated version to reach the end user, by systematically eliminating redundant steps or using the prototype methods. Cost overruns and meeting the time constraints are another advantage, though not a big consideration in high-end uses. RAD makes the development process to be a more credible one by facilitating a scope for the customer to actively provide inputs in the development process. This may also prove a feasible study from the point of view of a developer.

29

•

It protects the current project from the variations in the market.

Rapid Application Development is an efficient methodology which can assist faster software development, and at the same time ensure maximum quality of the project.

30