Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.

Slides:



Advertisements
Similar presentations
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advertisements

Architectural Mismatch: Why Reuse Is So Hard David Garlan, Robert Allen, and John Ockerbloom Presented by Hoang Bao CSC 509 – Winter 2005.
Classes and Object- Oriented... tMyn1 Classes and Object-Oriented Programming The essence of object-oriented programming is that you write programs in.
7M701 1 Software Engineering Object-oriented Design Sommerville, Ian (2001) Software Engineering, 6 th edition: Chapter 12 )
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
The Architecture Design Process
Lecture 23: Software Architectures
Design Patterns Module Name - Object Oriented Modeling By Archana Munnangi S R Kumar Utkarsh Batwal ( ) ( ) ( )
1 An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt.
Software Life Cycle Model
Seminar of “CBSE” Course Mohammad Mahdizadeh SM. University of Science and Technology Mazandaran-Babol January 2010 Adaptation of.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Problems with reuse – Increased maintenance costs; lack of tool support; not-invented- here syndrome; creating, maintaining, and using a component library.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
11 1 Object oriented DB (not in book) Database Systems: Design, Implementation, & Management, 6 th Edition, Rob & Coronel Learning objectives: What.
1/19 Component Design On-demand Learning Series Software Engineering of Web Application - Principles of Good Component Design Hunan University, Software.
1 N Degrees of Separation: Multi-Dimensional Separation of Concern (MDSOC) HyperJ: language and concepts of general concern combination.
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture 11 : Frameworks SWE 316: Software Design and Architecture  To understand.
An Introduction to Software Architecture
CSE 303 – Software Design and Architecture
02/10/2015 Page 1 R. Theeuws Siemens Atea Filename: CBD_ervaring Werkgroep Component Based Developments Ervaring CBD.
Teaching material for a course in Software Project Management & Software Engineering – part II.
1 SYS366 Lecture 1: Introduction to Systems. 2 What is Software Development? Software Development implies developing some software – but it does not involve.
OHTO -99 SOFTWARE ENGINEERING LECTURE 5 Today: - An overview to OO Analysis and OO Design - Introduction of Assignment 2.
An Introduction to Design Patterns. Introduction Promote reuse. Use the experiences of software developers. A shared library/lingo used by developers.
Architectural Design To explain the advantages and disadvantages of different distributed systems architectures To discuss client-server and distributed.
Putting together a complete system Chapter 10. Overview  Design a modest but complete system  A collection of objects work together to solve a problem.
Chapter 11: Software Prototyping Omar Meqdadi SE 273 Lecture 11 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
SOFTWARE SYSTEMS DEVELOPMENT 4: System Design. Simplified view on software product development process 2 Product Planning System Design Project Planning.
Architectural Design lecture 10. Topics covered Architectural design decisions System organisation Control styles Reference architectures.
Chapter 13: Regression Testing Omar Meqdadi SE 3860 Lecture 13 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
The Systems Development Life Cycle
 Repository Model  Client-Server Model  Layered Model  Modular decomposition styles  Object Models  Function Oriented Pipelining  Control Styles.
Chapter 8 Object Design Reuse and Patterns. Object Design Object design is the process of adding details to the requirements analysis and making implementation.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Lecture 14 Maintaining the System and Managing Software Change SFDV Principles of Information Systems.
FDT Foil no 1 On Methodology from Domain to System Descriptions by Rolv Bræk NTNU Workshop on Philosophy and Applicablitiy of Formal Languages Geneve 15.
1 Ch. 1: Software Development (Read) 5 Phases of Software Life Cycle: Problem Analysis and Specification Design Implementation (Coding) Testing, Execution.
Chapter 7: Architectural Design Chapter 11 in textbook 1.
Chapter 2: Software Maintenance Omar Meqdadi SE 3860 Lecture 2 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
Developing Product Line Components Jan Bosch Professor of Software Engineering University of Groningen, Netherlands
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
 Many models have been proposed to deal with the problems of defining activities and associating them with each other  The first model proposed was the.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Chapter 10 Software quality. This chapter discusses n Some important properties we want our system to have, specifically correctness and maintainability.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Of 24 lecture 11: ontology – mediation, merging & aligning.
Software Design and Development Development Methodoligies Computing Science.
Advanced Software Engineering Dr. Cheng
Chapter (12) – Old Version
Design Patterns: MORE Examples
Lecture 3 Prescriptive Process Models
Introduction to Design Patterns
Chapter 11 Object-Oriented Design
Part 3 Design What does design mean in different fields?
Classical Waterfall Model
Life Cycle Models PPT By :Dr. R. Mall.
Designing Software for Ease of Extension and Contraction
Princess Nourah bint Abdulrahman University
Chapter 9 – Software Evolution and Maintenance
An Introduction to Software Architecture
CS310 Software Engineering Lecturer Dr.Doaa Sami
Chapter 8 Software Evolution.
Practical Database Design and Tuning Objectives
Presentation transcript:

Banaras Hindu University

A Course on Software Reuse by Design Patterns and Frameworks

by Dr. Manjari Gupta Department of Computer Science Banaras Hindu University

Lecture 15 Problems in OO Frameworks (Part-2)

Framework Composition Problems

 the architectural styles based on which the frameworks are designed are different,  complicating composition so much that it may be impossible to compose.  specifying the architectural style underlying a framework design seems to be the first step towards a solution Architectural mismatch

 two (or more) frameworks are used that combined cover the application requirements.  If both frameworks contain a representation (e.g. a class) of the same real-world entity, but modelled from their respective perspectives.  the real-world entity should be modelled by a single object and the two representations should be integrated into one.  the composition of properties from the frameworks classes is not as straightforward Overlap of framework entities

 an application in 3-tier application architecture.  to compose the application from a user-interface framework, a framework covering the application domain concepts and a framework providing database functionality.  The real world entity is represented in the application domain framework.  However, aspects of the entity have to be presented in some user interface and the entity has to be made persistent and suited for transactions and such. Composition of entity functionality

 the behaviour from the user-interface and database framework classes needs to be superimposed on the object  this type of composition is not available in object- oriented languages  extending the application domain class with behaviour for notifying the user-interface and database classes, e.g. using the Observer design pattern is required Composition of entity functionality Cont…

 when composing two calling frameworks is that both expect to be the controlling entity in the application and in control of the main event loop  two control loops would conflict leading to incorrect behaviour  give each framework its own thread of control  all application objects that can be accessed by both frameworks need to be extended with synchronisation code Hollywood principle

 Drawback of synchronization code  Since a class often cannot be modularly extended with synchronization code, it requires that all reused classes are edited to add this.  often one framework needs to be informed about an event that occurred in the other framework because the event has application-wide relevance.  The control loops of the frameworks become much more integrated that two concurrent threads Hollywood principle Cont…

 existing (legacy) classes can be included in the application  When the framework class only contains behaviour for internal framework functionality and not much of the behaviour required for the application at hand  Integrating these legacy classes in application is difficult  framework depends on the subclassing mechanism  some form of adaptation or bridging Integrating legacy components

 Iteration between the phases is very frequent  changes/refactorings related to inheritance hierarchies and component hierarchies are of relevance for framework iteration  just before releasing the first version of the framework.  It involves a considerable amount of simple but tedious work  It would benefit from tool support. Framework Evolution & Maintenance

 The correction of an error in the framework is not as simple  The error should be corrected for the current application developed with the framework  The error should be handled in the existing applications developed with the framework  either split the framework into two separate frameworks that will need to be maintained or  to implement a work-around for the current application and live with the maintenance problems for the application. Framework Evolution & Maintenance Cont…

 it is difficult to know the exact domain boundary that has to be captured.  business changes in the organisation supporting the framework may require the domain must be adapted accordingly.  it is unclear how these kinds of business domain changes affect the existing framework. Framework Evolution & Maintenance Cont…

Framework Evolution & Maintenance Problems

 error could either be in the framework or in the application specific code.  should all applications be upgraded with the corrected version of the framework?  a number of problems will be found that require changes of the framework when the first real application is developed.  The identification of errors will not stop after the first application development and a problem is how to deal with subsequent application developments. Framework change

 Possibility of change  domain covered by the framework was incomplete  the current application to be developed has a bad fit to the framework’s domain  Deciding the maintenance strategy  To redesign the framework or  do a work-around for this specific application to overcome the problems.  Depends on time-pressure, estimated life-times for the software involved, existing and expected future applications etc. Choice of maintenance strategy

 the business domain is often weakly defined and not stable over time  three approaches attacking the problem of business doming change  One may define the original framework domain much wider than currently useful  handle the business domain change problem by redesigning the framework  reuse ideas from the original framework and develop a framework for the new business domain Business domain change

 framework development is an iterative process  two important problems with the iterations  it is expensive and difficult to predict the amount of resources needed for a framework project  it is difficult to stop iterating and decide that the framework is ready for release  a design iteration is a modification activity resulting from testing Design iterations

 Differences between traditional testing and Framework testing  If errors are detected  may require a redesign of the framework.  may also invalidate existing test applications that then need to be modified accordingly  three issues that are open for improvements  quantitative and qualitative guidelines of when to stop framework design  methods that can predict the number of iterations and the corresponding effort involved.  whether it is possible to evaluate a framework for a specific application without completely writing a test application Design iterations Cont…