Object-Oriented Software Engineering Practical Software Development using UML and C++ / Java Chapter 3: Basing Software Development on Reusable Technology

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology Building on the Experience of Others Software engineers should avoid re-developing software already developed Types of Reuse: Reuse of expertise Reuse of standard designs and algorithms Reuse of libraries of classes or procedures Reuse of powerful commands built into languages and operating systems Reuse of frameworks Reuse of complete applications

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology Reusability and Reuse in SE Reuse and design for reusability should be part of the culture of software development organizations But there are problems to overcome: Why take the extra time needed to develop something that will benefit other projects/customers? Management may only reward the efforts of people who create the visible ‘final products’. Reusable software is often created in a hurry and without enough attention to quality.

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 4 A vicious cycle Developers tend not develop high quality reusable components, so there is often little to reuse To solve the problem, recognize that: This vicious cycle costs money Investment in reusable code is important Attention to quality of reusable components is essential —So that potential re_users have confidence in them —The quality of a software product is only as good as its lowest-quality reusable component Developing reusable components can often simplify design

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology Frameworks: Reusable Subsystems A framework is reusable software that implements a generic solution to a generalized problem. EX.Net It provides common facilities applicable to different application programs. Principles: Applications that do different, but related, things tend to have quite similar designs

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 6 Frameworks to promote reuse A framework is intrinsically incomplete Certain classes or methods are used by the framework, but are missing (slots)‏ Some functionality is optional — Allowance is made for developer to provide it (hooks) Developers use the services that the framework provides —Taken together the services are called the Application Program Interface (API)‏

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 7 Object-oriented Frameworks In the object oriented paradigm, a framework is composed of a library of classes. The API is defined by the set of all public methods of these classes. Some of the classes will normally be abstract

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 8 Examples of frameworks A framework for payroll management A framework for university registration A framework for e-commerce web sites A framework for controlling microwave ovens

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 9 Types of Frameworks A horizontal framework provides general application facilities that a large number of applications can use A vertical framework (application framework) is more ‘complete’ but still needs some slots to be filled to adapt it to specific application needs

E.g Horizontal & Vertical frameworks Horizontal : if many applications need to have a “preference” dialog that allows user to specify many kinds of option, then a horizontal framework could be designed that would provide general “preferences dialog facilities” for many different types of applications. Vertical: the microwave oven, frequent-buyer and course registration frameworks are vertical in nature, while the E-Commerce framework might be hybrid. E.g(p74) an application will typically use only a subset of the framework’s services. like the framework of rental store could do such things as manage membership, handle deposits, process rentals and returns and compute penalties for late return. Developer using this framework to build an application for a video rental store would likely ignore the facilities for handling deposits, but would take advantage of the membership facilities. E.g. (When building a car-rental system, the opposite would be true).

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology Risks when Reusing technology Poor quality reusable components —Ensure that the developers of the reusable technology: -follow good software engineering practices - are willing to provide active support Compatibility not maintained —Avoid obscure features —Only re-use technology that others are also re-using

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 12 Risks when developing reusable technology Investment uncertainty —Plan the development of the reusable technology, just as if it was a product for a client The ‘not invented here syndrome’ —Build confidence in the reusable technology by: -Guaranteeing support -Ensuring it is of high quality -Responding to the needs of its users

© Lethbridge/Laganière 2005 Chap. 3: Basing Development on Reusable Technology 13 Risk when developing reusable technology – continued Competition —The reusable technology must be as useful and as high quality as possible Divergence (tendency of various groups to change technology in different ways)‏ —Design it to be general enough, test it and review it in advance

14 Chapter 3 SOFTWARE DEVELOPMENT Process Models (taken from Sommerville text book)

15 Outline WHAT IS A SOFTWARE PROCESS? WHY SOFTWARE MODELS ARE CREATED? VARIOUS SOFTWARE MODELS UML IS ONE OF SOFTWARE MODELS

16 Generic phases of Software Engineering Definition phase Focuses on what. Identifying what function and performances are desired, what constraints exists etc. Development phase Focuses on how. Defining how data are to be structured, how function is to be implemented, how the design will be translated into a programming language. Support phase Focuses on change to the developed software. 4 types of change: Correction, Adaptation, Enhancement & Prevention.

17 Possible Identification of Software Development Activities Requirements Analysis What is the problem? System Design What is the solution? Program Design What are the mechanisms that best implement the solution? Program Implementation How is the solution constructed? Testing Is the problem solved? Delivery Can the customer use the solution? Maintenance Are enhancements needed? Problem Domain Problem Domain Implementation Domain Implementation Domain

18 Software Process Models Many models have been proposed to deal with the problems of defining activities and associating them with each other Example: —Waterfall Model —The Incremental Model —The RAD Model —Evolutionary Model – Prototyping, Spiral & Concurrent

19 The Waterfall Model

20 The Incremental Model

21 Evolutionary Models: Prototyping communication Quick plan Modeling Quick design Construction of prototype Deployment delivery & feedback

22 The RAD Model

23 Waterfall Model Problems The user can’t see final system until the test phase When finished, the software may unusable, because of the changes that might occur The user is expected to agree with a supposedly complete requirements specification which cannot possibly be completely understood since there are no working examples to demonstrate the functionality of the proposed system early in its development. Conclusion: This model is only appropriate when the requirements are well- understood.

24 Benefits of Prototyping The user are stimulated to discover requirements that they might not thought of until after full implementation using waterfall method. As a quality control technique. Dramatically raise the level of customer satisfaction with the functionality of delivered software. Software which delivered using this approach contains fewer functional defects.

25 Limitations of Prototyping Could result in many trial systems since configuration and version control of prototypes may be more difficult than with conventional development. Keeping documentation current may be difficult in prototyping because of its rapidly changing and iterative nature. It is difficult to maintain documentation in a reasonable condition during prototyping. Prototype may be unsuitable for translation into larger systems, the designs produced by prototyping may be too narrowly focused or the tools employed unsuitable for scaling the prototype up into a full-sized working system. Can disrupt / distract customers, the much greater involvement of customers in software development is bound to take considerable time and effort on their part.

26 Still Other Process Models Component based development—the process to apply when reuse is a development objective Formal methods—emphasizes the mathematical specification of requirements AOSD—provides a process and methodological approach for defining, specifying, designing, and constructing aspects Unified Process—a “use-case driven, architecture-centric, iterative and incremental” software process closely aligned with the Unified Modeling Language (UML)

27 inception The Unified Process (UP) inception elaboration

28 UP Phases

Chapter 3 29 The Phases of the Unified Process (contd) The four increments are labeled Inception phase Elaboration phase Construction phase Transition phase The phases of the Unified Process are the increments In theory, there could be any number of increments In practice, development seems to consist of four increments Every step performed in the Unified Process falls into One of the five core workflows and also One of the four phases Why does each step have to be considered twice?

Chapter 3 30 The Inception Phase The aim of the inception phase is to determine whether the proposed software product is economically viable. To do this we need to: 1.Gain an understanding of the domain 2.Build the business model 3.Delimit the scope of the proposed project Focus on the subset of the business model that is covered by the proposed software product 4.Begin to make the initial business case Phases InceptionElaborationConstructionTransition

Chapter 3 31 The Inception Phase : The Initial Business Case Questions that need to be answered include: Is the proposed software product cost effective? How long will it take to obtain a return on investment? Alternatively, what will be the cost if the company decides not to develop the proposed software product? If the software product is to be sold in the marketplace, have the necessary marketing studies been performed? Can the proposed software product be delivered in time? If the software product is to be developed to support the client organization’s own activities, what will be the impact if the proposed software product is delivered late?

Chapter 3 32 The Inception Phase: The Initial Business Case What are the risks involved in developing the software product, and How can these risks be mitigated? Does the team who will develop the proposed software product have the necessary experience? Is new hardware needed for this software product? —If so, is there a risk that it will not be delivered in time? —If so, is there a way to mitigate that risk, perhaps by ordering back-up hardware from another supplier? Are software tools (Chapter 5) needed? —Are they currently available? —Do they have all the necessary functionality?

Chapter 3 33 The Inception Phase: Risks There are three major risk categories: Technical risks —See earlier slide The risk of not getting the requirements right —Mitigated by performing the requirements workflow correctly The risk of not getting the architecture right —The architecture may not be sufficiently robust To mitigate all three classes of risks The risks need to be ranked so that the critical risks are mitigated first This concludes the steps of the inception phase that fall under the requirements workflow

Chapter 3 34 The Inception Phase: Analysis, Design. Test A small amount of the analysis workflow may be performed during the inception phase Information needed for the design of the architecture is extracted Accordingly, a small amount of the design workflow may be performed, too Coding is generally not performed during the inception phase However, a proof-of-concept prototype is sometimes build to test the feasibility of constructing part of the software product The test workflow commences almost at the start of the inception phase The aim is to ensure that the requirements have been accurately determined

Chapter 3 35 The Inception Phase: Planning There is insufficient information at the beginning of the inception phase to plan the entire development The only planning that is done at the start of the project is the planning for the inception phase itself For the same reason, the only planning that can be done at the end of the inception phase is the plan for just the next phase, the elaboration phase

Chapter 3 36 Elaboration Phase The aim of the elaboration phase is to refine the initial requirements Refine the architecture Monitor the risks and refine their priorities Refine the business case Produce the project management plan The major activities of the elaboration phase are refinements or elaborations of the previous phase The tasks of the elaboration phase correspond to: All but completing the requirements workflow Performing virtually the entire analysis workflow Starting the design of the architecture Phases InceptionElaborationConstructionTransition

Chapter 3 37 Construction Phase The aim of the construction phase is to produce the first operational-quality version of the software product This is sometimes called the beta release The emphasis in this phase is on Implementation, and Testing —Unit testing of modules —Integration testing of subsystems —Product testing of the overall system Phases InceptionElaborationConstructionTransition

Chapter 3 38 The Transition Phase The aim of the transition phase is to ensure that the client’s requirements have indeed been met Faults in the software product are corrected All the manuals are completed Attempts are made to discover any previously unidentified risks This phase is driven by feedback from the site(s) at which the beta release has been installed The deliverables of the transition phase include: All the artifacts (final versions) The completed manuals Phases InceptionElaborationConstructionTransition

Chapter 3 39 Phase Deliverables Inception PhaseElaboration PhaseConstruction PhaseTransition Phase  The initial version of the domain model  The initial version of the business model  The initial version of the requirements artifacts  A preliminary version of the analysis artifacts  A preliminary version of the architecture  The initial list of risks  The initial ordering of the use cases  The plan for the elaboration phase  The initial version of the business case  The completed domain model  The completed business model  The completed requirements artifacts  The completed analysis artifacts  An updated version of the architecture  An updated list of risks  The project management plan (for the rest of the project)  The completed business case  The initial user manual and other manuals, as appropriate  All the artifacts (beta release versions)  The completed architecture  The updated risk list  The project management plan (for the remainder of the project)  If necessary, the updated business case  All the artifacts (final versions)  The completed manuals