EPL603 Topics in Software Engineering
|
|
- Philomena Goodman
- 6 years ago
- Views:
Transcription
1 Lecture 4 - Software Reuse EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740
2 Topics covered Software reuse The reuse landscape Design reuse Libraries or toolkits Application frameworks Design patterns Architectures Software product lines COTS product reuse ERP Systems Lecture 4: Software reuse 2
3 Software reuse (1/4) Reuse is often referred to as not reinventing the wheel. In most engineering disciplines, systems are designed by composing existing components that have been used in other systems. Lecture 4: Software reuse 3
4 Software reuse (2/4) The ability to reuse software relies in the ability to build larger systems from smaller parts, and being able to identify commonalities among those parts. The level of reuse in each system may vary. (a) (b) (c) Reuse maturity level Lecture 4: Software reuse 4
5 Software reuse (3/4) Software engineering has been more focused on original development but it is now recognised that to achieve better software, more quickly and at lower cost, we need a design process that is based on systematic software reuse. There has been a major switch to reuse-based development over the past 10 years. By software reuse we mean the repeated use of any part of a software system, such as, documentation, code, design, requirements, test cases and test data. Software researchers believe that reuse has great potential for increasing productivity and reducing cost and some efforts to apply reuse technologies confirmed their belief. [Pfleeger and Atlee, 2010] Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Lecture 4: Software reuse 5
6 Software reuse (4/4) Software reuse is the process whereby an organization defines a set of systematic operating procedures to specify, produce, classify, retrieve and adapt software artefacts for the purpose of using them in its development activities. [Mili et al., 2002] Software artefacts include all software products, from requirements and proposals, to specifications and designs, to source code, to components, development artefacts, to patterns, and templates, to user manuals and test suites. Anything that is produced from a software development effort can potentially be reused. Source: Mili et al., Reuse Based Software Engineering: Techniques, Organization, and Measurement. Wiley, 2002 Lecture 4: Software reuse 6
7 Reuse-based software engineering Application system reuse The whole of an application system may be reused either by incorporating it without change into other systems (COTS reuse) or by developing application families. Little or no original software development is required; a whole system is configured for the needs of an organization. Component reuse Components of an application from sub-systems to single objects may be reused. Object and function reuse Software components that implement a single well-defined object or function may be reused. the unit of reuse Lecture 4: Software reuse 7
8 Reuse-based software engineering process Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, Lecture 4: Software reuse 8
9 Benefits of software reuse (1/2) Benefit Increased dependability Reduced process risk Effective use of specialists Explanation Reused software, which has been tried and tested in working systems, should be more dependable than new software. Its design and implementation faults should have been found and fixed. The cost of existing software is already known, whereas the costs of development are always a matter of judgment. This is an important factor for project management because it reduces the margin of error in project cost estimation. This is particularly true when relatively large software components such as subsystems are reused. Instead of doing the same work over and over again, application specialists can develop reusable software that encapsulates their knowledge. Lecture 4: Software reuse 9
10 Benefits of software reuse (2/2) Benefit Standards compliance Accelerated development Explanation Some standards, such as user interface standards, can be implemented as a set of reusable components. For example, if menus in a user interface are implemented using reusable components, all applications present the same menu formats to users. The use of standard user interfaces improves dependability because users make fewer mistakes when presented with a familiar interface. Bringing a system to market as early as possible is often more important than overall development costs. Reusing software can speed up system production and efficiency because both development and validation time may be reduced. Lecture 4: Software reuse 10
11 Substantial return on investment (1/2) Metrics collected in two reuse programs at Hewlett-Packard demonstrated improved quality, increased productivity, and reduced time to market. Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Lecture 4: Software reuse 11
12 Substantial return on investment (2/2) Ericsson engineering teams in Sweden and Norway built two largescale, distributed telecom systems containing several reused components. The systems were evaluated in terms of the effect of software reuse on product defects and stability. The analysis showed that reused components had a lower defect density than non-reused ones, with defect density calculated by dividing the number of defects by the number of lines of code. Among successive releases reusable components were less likely to be modified, as measured by the percentage of code that was modified. Thus, the reused components were far more stable than their non-reused counterparts. Source: Mohagheghi, P., R. Conradi, O.M. Killi, and H. Schwarz. An Empirical Study of Software Reuse Vs. Defect-density and Stability. In 26th International Conference on Software Engineering, ICSE Proceedings, , Lecture 4: Software reuse 12
13 Problems with reuse (1/2) Problem Increased maintenance costs Lack of tool support Not-invented-here (ΝΙΗ) syndrome Explanation If the source code of a reused software system or component is not available then maintenance costs may be higher because the reused elements of the system may become increasingly incompatible with system changes. Some software tools do not support development with reuse. It may be difficult or impossible to integrate these tools with a component library system. The software process assumed by these tools may not take reuse into account. This is particularly true for tools that support embedded systems engineering, less so for object-oriented development tools. Some software engineers prefer to rewrite components because they believe they can improve them or they believe they cannot be any good unless they wrote it themselves. This is partly to do with trust and partly to do with the fact that writing original software is seen as more challenging than reusing other people s software. Lecture 4: Software reuse 13
14 Problems with reuse (2/2) Problem Creating, maintaining, and using a component library is expensive Finding, understanding, and adapting reusable components is difficult Legal issues Explanation Populating a reusable component library and ensuring the software developers can use this library can be expensive. Development processes have to be adapted to ensure that the library is used. Software components have to be discovered in a library, understood and, sometimes, adapted to work in a new environment. Engineers must be reasonably confident of finding a component in the library before they include a component search as part of their normal development process. Legal issues can arise with contract software. Usually in the type of contracts drawn up between a client and a software development organization, the software product belongs to the customer. Therefore, if a developer reuses a component of one client s product essentially violates the first client s copyright. Sources : Sommerville, I., Software Engineering, 9th ed., Addison Wesley, 2010 Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, 2007 Lecture 4: Software reuse 14
15 Experiences with reuse Raytheon A Missile Systems Division s Information Processing Systems Organization. Observed 60% of its business applications design and code were redundant and thus were good candidates for reuse. Classified source code into 3 major module classes (edit, update and report). Reported that a new system contained an average of 60% reused code, increasing productivity by 50%. GTE Data Services Established incentives and rewards for programmers, i.e., they were paid: Up to $100 for every component accepted to the library Royalties whenever their components were reused by a new project. Bonus for the reuser of the month award. In the first year, reported 14% reuse on its projects, valued at a savings of $1.5m. Nippon Novel Paid 5c per line of code to a developer who reused a component. The program cost far less than the cost of writing the equivalent code. However, some organizations have reported cost increases for making a component reusable of 200% up to 480%. Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 15
16 Open source software reuse Open source development is an approach to software development in which the source code of a software system is published and volunteers are invited to participate in the development process Its roots are in the Free Software Foundation ( which advocates that source code should not be proprietary but rather should always be available for users to examine and modify as they wish. Open source systems offer an opportunity for effective software reuse since it provides rich collection of software projects. Examples of best-known open source product is, of course, the Linux OS which is widely used as a server system and, increasingly, as a desktop environment. Other important open source products are Java, the Apache web server and the mysql database management system. Skip OSS Lecture 4: Software reuse 16
17 Open source issues Should the product that is being developed make use of open source components? The type of software developed should be taken into consideration. If the software is for sale, then time to market and reduced costs are critical. The domain for which the software is developed is also critical. If for the domain you are developing there are high-quality open source systems available, then you can save time and money by using these systems. If the system has specific set of organizational requirements, then open source components may not be an option. You may have to integrate your software with existing systems that are compatible with available open source systems. Even then, it could be quicker and cheaper to modify the open source system rather than redevelop the functionality that you need. Lecture 4: Software reuse 17
18 Open source licensing (1/2) A fundamental principle of open-source development is that source code should be freely available; this does not mean that anyone can do as they wish with that code. Legally, the developer of the code (either a company or an individual) still owns the code. They can place restrictions on how it is used by including legally binding conditions in an open source software license. Some open source developers believe that if an open source component is used to develop a new system, then that system should also be open source. Others are willing to allow their code to be used without this restriction. The developed systems may be proprietary and sold as closed source systems Richard Stallman in Hackers: Wizards of the Electronic Age, Internet and Web Pioneers: Richard Stallman, Lecture 4: Software reuse 18
19 Open source licensing (2/2) The GNU General Public License (GPL) This is a so-called reciprocal license that means that if you use open source software that is licensed under the GPL license, then you must make that software open source. The GNU Lesser General Public License (LGPL) This is a variant of the GPL license where you can write components that link to open source code without having to publish the source of these components. The Berkley Standard Distribution (BSD) License This is a non-reciprocal license, which means you are not obliged to re-publish any changes or modifications made to open source code. You can include the code in proprietary systems that are sold. Lecture 4: Software reuse 19
20 The reuse landscape (1/2) Although reuse is often simply thought of as the reuse of system components, there are many different approaches to reuse that may be used. Reuse is possible at a range of levels from simple functions to complete application systems. The reuse landscape covers the range of possible reuse techniques. Lecture 4: Software reuse 20
21 The reuse landscape (2/2) Application frameworks Component-based software engineering Model-driven engineering Service-oriented systems Design patterns Legacy system wrapping Software product lines COTS integration Configurable vertical applications Program libraries Architectural patterns Aspect-oriented software development ERP systems Program generators Lecture 4: Software reuse 21
22 Approaches that support software reuse (1/3) Approach Architectural patterns Design patterns Component-based software development (CBSE) Legacy system wrapping Description Standard software architectures that support common types of application systems are used as the basis of applications. Generic abstractions that occur across applications are represented as design patterns showing abstract and concrete objects and interactions. Systems are developed by integrating components (collections of objects) that conform to component-model standards. Legacy systems (old systems that are still useful and are often critical to business operations) are wrapped by defining a set of interfaces and providing access to these legacy systems through these interfaces. Lecture 4: Software reuse 22
23 Approaches that support software reuse (2/3) Approach Application frameworks Service-oriented systems Software product lines (SPL) COTS product reuse ERP systems Configurable vertical applications Description Collections of abstract and concrete classes are adapted and extended to create application systems. Systems are developed by linking shared services, which may be externally provided. An application type is generalized around a common architecture so that it can be adapted for different customers. Systems are developed by configuring and integrating existing application systems. Large-scale systems that encapsulate generic business functionality and rules are configured for an organization. Generic systems are designed so that they can be configured to the needs of specific system customers. Lecture 4: Software reuse 23
24 Approaches that support software reuse (3/3) Approach Program libraries Model-driven engineering Program generators Aspect-oriented software development Description Class and function libraries that implement commonly used abstractions are available for reuse. Software is represented as domain models and implementation independent models and code is generated from these models. A generator system embeds knowledge of a type of application and is used to generate systems in that domain from a user-supplied system model. Shared components are woven into an application at different places when the program is compiled. Lecture 4: Software reuse 24
25 Types of reuse and domain analysis Vertical reuse Involves the same application area or domain. Horizontal reuse Does not involve the same domain, but cuts across domains. [Pfleeger & Atlee] With any form of reuse a robust library needs to be discovered. The process where the entities in libraries are determined to be appropriate for use in new applications is the domain analysis process. Domain analysis process is the process of identification, analysis and specification of common requirements from a specific application domain, typically for reuse on multiple projects within the application domain. [Pressman] Sources: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Pressman, R.S., Software Engineering: a Practitioner s Approach, 5th Rev. Ed., McGraw-Hill, Lecture 4: Software reuse 25
26 Reuse planning factors (1/2) Factor Development schedule Expected lifetime Development team Criticality and nonfunctional requirements Description If the software has to be developed quickly, use COTS integration rather than CBSE. Even though the fit to requirements may be imperfect, it minimizes the amount of development required. If the system lifetime is long the maintainability of the system is critical. Probably it is better to avoid reuse with unavailable or inaccessible code, such as COTS and systems from external suppliers; suppliers may not be able to continue support for the reused software. All reuse technologies are fairly complex. If the development teams background, skills and experience is related to any of the reuse areas, this is probably where you should turn in to. If the systems is a critical system (e.g., has stringent performance requirements) it is probably better to avoid using unavailable or inaccessible source code or generator-based reuse (generate code from a reusable domain-specific representation of a system). Lecture 4: Software reuse 26
27 Reuse planning factors (2/2) Factor Application domain Application Platform Description If the system is for a specific application domain, such as manufacturing and medical information systems, several configurable vertical application reuse methods may be considered a good solution. There are several generic products that may be reused for configuring them to a local solution. Consider the platform your system is designed for; you may only be able to use specific components. Also, if the component models or generic application systems you are using are platform-specific, such as.net component models are specific to Microsoft platforms, you may only be able to reuse these. Lecture 4: Software reuse 27
28 Black-box and white-box reuse Black-box reuse Assets are integrated into target system without modification. Greater benefit. Higher information hiding. Simplifies reuse for the consumer because he does not need to know the internal workings to compose assets. Harder to realize for the producer (the one that creates reusable components). Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, White-box reuse Assets are modified before they are integrated into the target system. Requires deep understanding of the inner-working of the asset. Requires re-assessment of the qualitative properties of the asset. Needs to be tested anew. Loss of guarantee from the producer. Smaller benefit. Lecture 4: Software reuse 28
29 Reuse during design and implementation During design different types of reuse may be carried out, some of which carry over into implementation. Reuse within: ( a) A library or a toolkit ( b) A framework ( c) A design pattern ( d) A software architecture (a) (b) (c) (d) Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 29
30 Reuse with a library or toolkit A library or a toolkit is used. Examples:. Java GUI Widget Toolkit The designer and developer are responsible for the control logic of the product as a whole. Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 30
31 Reuse with a library or toolkit benefits The library or toolkit supplies parts for conducting specific operations of the product. Tested modules (designs and implementations) are incorporated into the product. Thus, the overall design and implementation can be produced more quickly and it is likely to have a higher quality than when everything is created from scratch. Reuse with a library or toolkit problems Library reuse (rather than toolkit reuse) promotes code reuse more rather than design reuse. It can be alleviated with the object-oriented paradigm. Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 31
32 Reuse with a framework Software reuse with a framework is when designers design application-specific operations and specific classes are inserted from/into the framework. Examples: Framework for building online information systems in Java MacApp framework for application software on Macintosh Microsoft s Foundation Class Library (MFC) contains large collection of frameworks for building GUIs in Windows apps Visual Components Library (VCL) an update of Object Windows Library (OWL); similar functionality to MFC The designer and developer supply the control logic of specific operations. Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 32
33 Application frameworks Application frameworks consist of a software framework used by software developers to implement the standard structure of an application for a specific development environment (such as an operating system or a web application). Frameworks are moderately large entities that can be reused. Frameworks are somewhere between system and component reuse. Frameworks are sub-system designs made up of a collection of abstract and concrete classes and the interfaces between them. The sub-system is implemented by adding components to fill in parts of the design and by instantiating the abstract classes in the framework. Lecture 4: Software reuse 33
34 Framework classes System infrastructure frameworks Support the development of system infrastructures such as communications, user interfaces and compilers. Middleware integration frameworks Standards and classes that support component communication and information exchange. Examples include Microsoft s.net and Enterprise Java Beans (EJB). Support standardized component models. Enterprise application frameworks Support the development of specific types of application such as telecommunications or financial systems. Embed application domain knowledge and support the development of end-user applications. Web application frameworks (WAF) Support the construction of dynamic websites and incorporate specialized features. Lecture 4: Software reuse 34
35 Web application frameworks WAF are widely applicable and support the construction of dynamic websites as a front-end for web applications. WAF are now available for all of the commonly used web programming languages e.g. Java, Python, Ruby, etc. Their architecture is based on the Model-View-Controller (MVC) composite pattern. Recommends the separation of the business logic from the presentation layer and the use of a controller to coordinate the flow of requests from the client to the server and the actions taken on those requests. Lecture 4: Software reuse 35
36 WAF features Security WAF may include classes to help implement user authentication (login) and access. Dynamic web pages Classes are provided to help you define web page templates and to populate these dynamically from the system database. Database support The framework may provide classes that provide an abstract interface to different databases. Session management Classes to create and manage sessions (a number of interactions with the system by a user) are usually part of a WAF. User interaction Most web frameworks now provide AJAX support, which allows more interactive web pages to be created. Lecture 4: Software reuse 36
37 Reuse with framework s benefits Frameworks are generic but can also be specialized to a domain. Frameworks reuse offers faster development than reuse with toolkits with libraries because: More of design is reused with frameworks and there is less to design from scratch. The portion of the design that is reused with a framework (the control logic) is harder to design than the functions; so the quality of the design is likely to be higher than when a toolkit is used. If the implementation is based on a framework then the resulting product is likely to be maintained easily because the control logic has already been tested in other products. Frameworks are often implementations of multiple design patterns. Frameworks are concrete and can be extended. Source: Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 37
38 Extending frameworks Frameworks are generic and are extended to create a more specific application or sub-system. They provide a skeleton architecture for the system. Extending the framework involves Adding concrete classes that inherit operations from abstract classes in the framework; Adding methods that are called in response to events that are recognised by the framework. Problem with frameworks is their complexity which means that it takes a long time to use them effectively. Lecture 4: Software reuse 38
39 Example with extending frameworks UML Notation package of classes Implementation abstract class package FrameworkPackage; abstract class AbstractClass... inheritance attribute method package FrameworkPackage; class DerivedClass extends AbstractClass { int att; void mymethod2 (ReferencedClass c) {...} } Lecture 4: Software reuse 39
40 Reuse with design patterns Design patterns consist of a solution to a general design problem in the form of a set of interacting classes that are customized to create a specific design. Example: We want a program that generates families of related objects, without specifying concrete classes. Interacting classes Abstract Car Factory Classes that must be customized for a specific product. Source: Schach, S.R., Object- Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 40
41 Abstract widget factory design pattern We want a program that generates widgets (menus, windows, scrollbars, sliders) that can run under different operating systems. Source: Schach, S.R., Object- Oriented and Classical Software Engineering, 7th ed., WCB/McGraw- Hill, Lecture 4: Software reuse 41
42 Reuse based on software architecture (1/2) Various architectures used for churches, cathedrals and temples. Ancient Greek, Doric (Parthenon, Greece) Byzantine (Hagia Sophia, Turkey) Gothic (façade) (Notre-Dame, France) Renaissance (façade) (Sant Andrea della Valle, Italy) Reuse in software architecture is applying a design of a product as a whole, and usually encompasses a variety of issues: Components organization and physical distribution Product-level control structures Communication and synchronization issues Databases and data access Source: Schach, S.R., Object- Choice of alternatives Oriented and Classical Software Engineering, 7th ed., WCB/McGraw- Lecture 4: Software reuse Hill,
43 Reuse based on software architecture (2/2) [defn] Abstractly, software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on those patterns. Architecture includes patterns as a subfield. Example: An architecture consisting of: A framework Three design patterns A toolkit Source: Schach, S.R., Object- Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Lecture 4: Software reuse 43
44 Software product lines (1/2) Software product lines or application families are collections of applications with generic functionality that can be adapted and configured for use in a specific context. A software product line is a set of applications with a common architecture and shared components, with each application specialized to reflect different requirements. A set of software intensive systems sharing a common managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.? refine / decide / plan [SEI, repository software assets package software products Lecture 4: Software reuse 44
45 Software product lines (2/2) High proportion of the application code is reused. Product lines embed detailed domain and platform information. Are made up of a family of applications, usually owned by the same organization. Adaptations may involve: Existing component and system configuration Adding new components to the system Selecting from a library of existing components Modifying components to meet new requirements Hall of fame case studies Examples Embedded software for mobile phones Control application for equipment (e.g, family of printers) Business support software Computer games Source: Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Lecture 4: Software reuse 45
46 Product instance development process Elicit stakeholder requirements Use existing family member as a prototype Choose closest-fit family member (starting point) Find the family member that best meets the requirements for modification Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, Re-negotiate requirements Adapt requirements as necessary to capabilities of the software, to minimize the changes needed. Adapt existing system Develop new modules and make changes for family member Deliver new family member Document key features for other member developments in the future Lecture 4: Software reuse 46
47 Product line specialization Platform specialization Different versions of the application are developed for different platforms. E.g., Windows, Mac OS, Linux. Environment specialization Different versions of the application are created to handle different operating environments e.g. different types of communication equipment (peripheral devices). Functional specialization Different versions of the application are created for customers with different requirements. Process specialization Different versions of the application are created to support different business processes. Lecture 4: Software reuse 47
48 COTS product reuse A commercial-off-the-shelf (COTS) product is a software system that can be adapted for different customers without changing the source code of the system. COTS systems have generic features and so can be used/reused in different environments. COTS products are adapted by using built-in configuration mechanisms that allow the functionality of the system to be tailored to specific customer needs. For example, in a hospital patient record system, separate input forms and output reports might be defined for different types of patients. Benefits with COTS reuse include: More rapid deployment of a reliable system may be possible. It is possible to see what functionality is provided by the applications and so it is easier to judge whether or not they are likely to be suitable. Businesses (the customers) can focus on their core activity without having to devote a lot of resources to IT systems development. Technology updates are simplified as are usually responsibility of the vendor. Lecture 4: Software reuse 48
49 Problems of COTS reuse Requirements usually have to be adapted to reflect the functionality and mode of operation of the COTS product. This may disrupt existing business processes. The COTS product may be based on assumptions that are practically impossible to change. The customer thus needs to adapt their business to these assumptions. Choosing the right COTS system for an enterprise can be a difficult process, especially as many COTS products are not well documented. There may be a lack of local expertise to support systems development. Thus, the customer relies on the vendor s advice which may be biased and geared to selling products and services rather than meeting the customer s real needs. The COTS product vendor controls system support and evolution. The vendor may go out of business, be taken over, or make changes that cause difficulties for customers. Lecture 4: Software reuse 49
50 COTS-solution and COTS-integrated systems (1/2) COTS-solution systems COTS-integrated systems Product Single product Several heterogeneous system products are integrated Functionality Provides the functionality required by a customer Provide customized functionality for customers Solution and processes Based around a generic solution and standardized processes Based on several flexible solutions that may be developed for supporting customer processes Development On system configuration On system integration focus Responsible for maintenance System vendor System owner Provides platform System vendor System owner for the system Lecture 4: Software reuse 50
51 COTS-solution and COTS-integrated systems (2/2) COTS-solution systems are generic application systems that may be designed to support a particular business type, business activity or, sometimes, a complete business enterprise. For example, a COTS-solution system may be produced for dentists that handles appointments, dental records, patient recall, etc. COTS-integrated systems are applications that include two or more COTS products and/or legacy application systems. One may prefer them when there is no single COTS system that meets all needs or when a new COTS product is integrated with systems that are already in use. Domain-specific COTS-solution systems, such as systems to support a business function (e.g. document management) provide functionality that is likely to be required by a range of potential users. For example, an Enterprise Resource Planning (ERP) system is a generic system that supports common business processes such as ordering and invoicing, manufacturing, etc. Lecture 4: Software reuse 51
52 The architecture of an ERP system A defined set of business processes, associated with each module, which relate to activities in that module. A set of business rules that apply to all data in the database. A number of modules to support different business functions. * * A common database that maintains information about all related business functions. Source: Sommerville, I., Software Engineering, 9th ed., Addison Wesley, Lecture 4: Software reuse 52
53 Issues in ERP configuration Select the required functionality from the system. Establish a data model that defines how the organization s data will be structured in the system database. Define business rules that apply to that data. Define the expected interactions with external systems. Design the input forms and the output reports generated by the system. Design new business processes that conform to the underlying process model supported by the system. Set parameters that define how the system is deployed on its underlying platform. Lecture 4: Software reuse 53
54 Design choices with COTS-solutions Which COTS products offer the most appropriate functionality? Typically, there will be several COTS products available, which can be combined in different ways. How will data be exchanged? Different products normally use unique data structures and formats. You have to write adaptors that convert from one representation to another. What features of a product will actually be used? COTS products may include more functionality than you need and functionality may be duplicated across different products. Lecture 4: Software reuse 54
55 Service-oriented COTS interfaces COTS-integration can be simplified if a service-oriented approach is used. A service-oriented approach means allowing access to the application system s functionality through a standard service interface, with a service for each discrete unit of functionality. Some applications may offer a service interface but, sometimes, this service interface has to be implemented by the system integrator. * * Build a wrapper that hides the application system and provides externally visible services. Lecture 4: Software reuse Source: Sommerville, I., Software Engineering, 9th ed., Addison 55 Wesley, 2010.
56 COTS-integration system problems Lack of control over functionality and performance COTS systems may be less effective than they appear. Problems with COTS system interoperability Different COTS systems may make different assumptions that means integration is difficult. No control over system evolution COTS vendors not system users control evolution. Support from COTS vendors COTS vendors may not offer support over the lifetime of the product. Lecture 4: Software reuse 56
57 Key points (1/2) Most new business software systems are now developed by reusing knowledge and code from previously implemented systems. There are many different ways to reuse software. These range from the reuse of classes and methods in libraries to the reuse of complete application systems. The advantages of software reuse are lower costs, faster software development and lower risks. System dependability is increased. Specialists can be used more effectively by concentrating their expertise on the design of reusable components. Reuse can be accomplished through a library or a toolkit, a framework, a design pattern and software architectures. Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialization and the addition of new objects. They usually incorporate good design practice through design patterns. Lecture 4: Software reuse 57
58 Key points (2/2) Software product lines are related applications that are developed from a common base. This generic system is adapted to meet specific requirements for functionality, target platform or operational configuration. COTS product reuse is concerned with the reuse of large-scale, commercial off-the-shelf systems. These provide a lot of functionality and their reuse can radically reduce costs and development time. Systems may be developed by configuring a single, generic COTS product or by integrating two or more COTS products. Enterprise Resource Planning (ERP) systems are examples of largescale COTS reuse. You create an instance of an ERP system by configuring a generic system with information about the customer s business processes and rules. Potential problems with COTS-based reuse include lack of control over functionality and performance, lack of control over system evolution, the need for support from external vendors and difficulties in ensuring that systems can inter-operate. Open Source? Lecture 4: Software reuse 58
59 Readings Chapter 16, Sommerville, I., Software Engineering, 9th ed., Addison Wesley, Chapter 8, Sections , Schach, S.R., Object-Oriented and Classical Software Engineering, 7th ed., WCB/McGraw-Hill, Chapter 12 Section 12.4, Pfleeger, S. L. and Atlee, J. M., Software Engineering, Fourth Edition, Pearson, Chapter 21 Sections /2 Pressman, R.S., Software Engineering: a Practitioner s Approach, 5th Rev. Ed., McGraw-Hill, Credits Slides adapted from Ian Sommerville Software Engineering, 9/E ( Lecture 4: Software reuse 59
Software Engineering
Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition)
More informationChapter 18. Software Reuse
Chapter 18 Software Reuse Ian Sommerville Lutz Prechelt Ian Sommerville 2004, Software Engineering, 7th edition, prechelt@inf.fu-berlin.de 1 Objectives To explain the benefits of software reuse and some
More informationSoftware Engineering Chap.7 - Design and Implementation
Software Engineering Chap.7 - Design and Implementation Simão Melo de Sousa RELEASE (UBI), LIACC (Porto), CCTC (Minho) Computer Science Department University of Beira Interior, Portugal Eng.Info./TSI,
More informationDr. Tom Hicks. Computer Science Department Trinity University
Dr. Tom Hicks Computer Science Department Trinity University 1 1 About Design With Reuse 2 Software Reuse Why Do We Care About Reuse? Historically: In Most Engineering Disciplines, Systems are Designed
More informationSeminar report Software reuse
A Seminar report On Software reuse Submitted in partial fulfillment of the requirement for the award of degree of Bachelor of Technology in Computer Science SUBMITTED TO: www.studymafia.com SUBMITTED BY:
More informationSOFTWARE ENGINEERING. To discuss several different ways to implement software reuse. To describe the development of software product lines.
SOFTWARE ENGINEERING DESIGN WITH COMPONENTS Design with reuse designs and develops a system from reusable software. Reusing software allows achieving better products at low cost and time. LEARNING OBJECTIVES
More informationGame Production: reuse
Game Production: reuse Fabiano Dalpiaz f.dalpiaz@uu.nl 1 Outline Lecture contents 1. Introduction to software reuse 2. Patterns 3. Application frameworks 4. Software product lines 5. Commercial-off-the-shelf
More informationSoftware Reuse and Component-Based Software Engineering
Software Reuse and Component-Based Software Engineering Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Contents Software Reuse Components CBSE (Component-Based Software Engineering) Domain Engineering
More informationChapter 7 Design and Implementation
Chapter 7 Design and Implementation Chapter 7 Design and Implementation Slide 1 Topics covered Object-oriented design using the UML Design patterns Implementation issues Reuse Configuration management
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationEPL603 Topics in Software Engineering
Lecture 5 Architectural Design & Patterns EPL603 Topics in Software Engineering Efi Papatheocharous Visiting Lecturer efi.papatheocharous@cs.ucy.ac.cy Office FST-B107, Tel. ext. 2740 Topics covered Software
More informationDesign and Implementa3on
Software Engineering Design and Implementa3on 1 Design and implementation Software design and implementation is the stage in the software engineering process at which an executable software system is developed.
More informationStudy of Component Based Software Engineering
Study of Based Software Ishita Verma House No.4, Village Dayalpur Karawal Nagar Road Delhi-110094, India ish.v.16@gmail.com Abstract based engineering is an approach of development that emphasizes the
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationComponent-based software engineering. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1
Component-based software engineering Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 19 Slide 1 Objectives To explain that CBSE is concerned with developing standardised components and
More informationObject-Oriented and Classical Software Engineering
Slide 8.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 8 Slide 8.2 REUSABILITY AND PORTABILITY Overview Slide
More informationPart 4. Development. -Software Reuse - Component-Based Software Engineering. JUNBEOM YOO Ver. 1.
Software Engineering Part 4. Development - Rapid Software Development -Software Reuse - Component-Based Software Engineering Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006.
More informationSOFTWARE ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationPart 5. Verification and Validation
Software Engineering Part 5. Verification and Validation - Verification and Validation - Software Testing Ver. 1.7 This lecture note is based on materials from Ian Sommerville 2006. Anyone can use this
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationIntroduction to Software Reuse
DCC / ICEx / UFMG Introduction to Software Reuse Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Software Reuse The use of existing software or software knowledge to build new software In the last
More informationLecture 2: Software Engineering (a review)
Lecture 2: Software Engineering (a review) Kenneth M. Anderson Object-Oriented Analysis and Design CSCI 6448 - Spring Semester, 2003 Credit where Credit is Due Some material presented in this lecture is
More informationObject-Oriented and Classical Software Engineering REUSABILITY AND PORTABILITY 11/5/2017. CHAPTER 8 Slide 8.2. Stephen R. Schach. Overview Slide 8.
Slide 8.1 CHAPTER 8 Slide 8.2 Object-Oriented and Classical Software Engineering REUSABILITY AND PORTABILITY Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 8.3 Overview Slide 8.4
More informationHow to Harvest Reusable Components in Existing Software. Nikolai Mansurov Chief Scientist & Architect
How to Harvest Reusable Components in Existing Software Nikolai Mansurov Chief Scientist & Architect Overview Introduction Reuse, Architecture and MDA Option Analysis for Reengineering (OAR) Architecture
More informationThis slide is relevant to providing either a single three hour training session or explaining how a series of shorter sessions focused on per chapter
Welcome to the OpenChain Curriculum Slides. These slides can be used to help train internal teams about FOSS compliance issues and to conform with the OpenChain Specification. You can deliver these slides
More informationLecture 15 Software Testing
Lecture 15 Software Testing Includes slides from the companion website for Sommerville, Software Engineering, 10/e. Pearson Higher Education, 2016. All rights reserved. Used with permission. Topics covered
More informationVerification and Validation. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1
Verification and Validation Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 22 Slide 1 Verification vs validation Verification: "Are we building the product right?. The software should
More informationSecond. Incremental development model
3 rd Stage Lecture time: 8:30 AM-2:30 PM Instructor: Ali Kadhum AL-Quraby Lecture No. : 4 Subject: Software Engineering Class room no.: Department of computer science Second. Incremental development model
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationLevel: M.Ed. Credit Hour: 3 (2+1) Semester: Second Teaching Hour: 80(32+48)
Course Title: Software Engineering Course No. : ICT Ed 528 Nature of course: Theoretical + Practical Level: M.Ed. Credit Hour: 3 (2+1) Semester: Second Teaching Hour: 80(32+48) 1. Course Description The
More informationFOUR INDEPENDENT TOOLS TO MANAGE COMPLEXITY INHERENT TO DEVELOPING STATE OF THE ART SYSTEMS. DEVELOPER SPECIFIER TESTER
TELECOM AVIONIC SPACE AUTOMOTIVE SEMICONDUCTOR IOT MEDICAL SPECIFIER DEVELOPER FOUR INDEPENDENT TOOLS TO MANAGE COMPLEXITY INHERENT TO DEVELOPING STATE OF THE ART SYSTEMS. TESTER PragmaDev Studio is a
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationCS 307: Software Engineering. Lecture 10: Software Design and Architecture
CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationComponent-based Architecture Buy, don t build Fred Broks
Component-based Architecture Buy, don t build Fred Broks 1. Why use components?... 2 2. What are software components?... 3 3. Component-based Systems: A Reality!! [SEI reference]... 4 4. Major elements
More informationTopics in Object-Oriented Design Patterns
Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationSoftware Processes. Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1
Software Processes Ian Sommerville 2006 Software Engineering, 8th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be
More informationSocket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.
Gang of Four Software Design Patterns with examples STRUCTURAL 1) Adapter Convert the interface of a class into another interface clients expect. It lets the classes work together that couldn't otherwise
More informationΗΜΥ 317 Τεχνολογία Υπολογισμού
ΗΜΥ 317 Τεχνολογία Υπολογισμού Εαρινό Εξάμηνο 2008 ΙΑΛΕΞΕΙΣ 16-17: Component-Based Software Engineering ΧΑΡΗΣ ΘΕΟΧΑΡΙ ΗΣ Λέκτορας ΗΜΜΥ (ttheocharides@ucy.ac.cy) [Προσαρμογή από Ian Sommerville, Software
More informationSoftware Testing. Massimo Felici IF
Software Testing Massimo Felici IF-3.46 0131 650 5899 mfelici@staffmail.ed.ac.uk What is Software Testing? Software Testing is the design and implementation of a special kind of software system: one that
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationCAS 703 Software Design
Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on Software by Tao et al. (Chapters 9 and 10) (SOA) 1 Interaction
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationTrends in Migration to Enterprise Space Ground Systems SMC-IT* Mini-workshop Summary
Trends in Migration to Enterprise Space Ground Systems SMC-IT* Mini-workshop Summary Michael Campbell, PhD Information Systems & Cyber Division Computer Applications and Assurance Subdivision The Aerospace
More informationComponent-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only
Chapter 10 Component-Level Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit
More informationChapter 8 Software Testing. Chapter 8 Software testing
Chapter 8 Software Testing 1 Topics covered Introduction to testing Stages for testing software system are: Development testing Release testing User testing Test-driven development as interleave approach.
More informationDesign Patterns. Observations. Electrical Engineering Patterns. Mechanical Engineering Patterns
Introduction o to Patterns and Design Patterns Dept. of Computer Science Baylor University Some slides adapted from slides by R. France and B. Tekinerdogan Observations Engineering=Problem Solving Many
More information09. Component-Level Design
09. Component-Level Design Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 What is Component OMG UML Specification defines a component as OO view a
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationMigration to Service Oriented Architecture Using Web Services Whitepaper
WHITE PAPER Migration to Service Oriented Architecture Using Web Services Whitepaper Copyright 2004-2006, HCL Technologies Limited All Rights Reserved. cross platform GUI for web services Table of Contents
More informationTopic : Object Oriented Design Principles
Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia Objectives Describe the differences between requirements activities and design activities
More informationKey Ideas. OO Analysis and Design Foundation. Objectives. Adapted from slides 2005 John Wiley & Sons, Inc.
Slide 1 Information Systems Development COMM005 (CSM03) Autumn Semester 2009 Dr. Jonathan Y. Clark Email: j.y.clark@surrey.ac.uk Course Website: www.computing.surrey.ac.uk/courses/csm03/isdmain.htm Course
More informationOrganizing and Managing Grassroots Enterprise Mashup Environments. Doctorial Thesis, 24 th June, Volker Hoyer
Organizing and Managing Grassroots Enterprise Mashup Environments Doctorial Thesis, 24 th June, 2010 Volker Hoyer Motivation and Research Questions Research Design Results Conclusion Motivation and Research
More informationChapter 17 - Component-based software engineering. Chapter 17 So-ware reuse
Chapter 17 - Component-based software engineering 1 Topics covered ² Components and component models ² CBSE processes ² Component composition 2 Component-based development ² Component-based software engineering
More informationOpen Server Architecture
EAB/OP-08:0052 Uen Rev A Open Server Architecture April 2008 Technology Paper The Open Server Architecture is flexible, open and easier to build applications on. This is achieved primarily through open
More informationChapter 6 Architectural Design
Chapter 6 Architectural Design Chapter 6 Architectural Design Slide 1 Topics covered The WHAT and WHY of architectural design Architectural design decisions Architectural views/perspectives Architectural
More informationTOPLink for WebLogic. Whitepaper. The Challenge: The Solution:
Whitepaper The Challenge: Enterprise JavaBeans (EJB) represents a new standard in enterprise computing: a component-based architecture for developing and deploying distributed object-oriented applications
More informationSOFTWARE ENGINEERING DECEMBER. Q2a. What are the key challenges being faced by software engineering?
Q2a. What are the key challenges being faced by software engineering? Ans 2a. The key challenges facing software engineering are: 1. Coping with legacy systems, coping with increasing diversity and coping
More informationCross-platform software development in practice. Object-Oriented approach.
Cross-platform software development in practice. Object-Oriented approach. Vitaly Repin Maemo Devices, Nokia Maemo March 25, 2010 (Maemo) Cross-platform software development. March 25, 2010 1 / 37 Outline
More informationQuestion 1: What is a code walk-through, and how is it performed?
Question 1: What is a code walk-through, and how is it performed? Response: Code walk-throughs have traditionally been viewed as informal evaluations of code, but more attention is being given to this
More informationLecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process
More informationChapter 4. Fundamental Concepts and Models
Chapter 4. Fundamental Concepts and Models 4.1 Roles and Boundaries 4.2 Cloud Characteristics 4.3 Cloud Delivery Models 4.4 Cloud Deployment Models The upcoming sections cover introductory topic areas
More informationStakeholder value, usage, needs and obligations from differnet types of F/LOSS licenses
Stakeholder value, usage, needs and obligations from differnet types of F/LOSS licenses Monash University, Melbourne Australia. darren.skidmore@infotech.monash.edu.au Abstract. This paper discusses different
More informationVendor: The Open Group. Exam Code: OG Exam Name: TOGAF 9 Part 1. Version: Demo
Vendor: The Open Group Exam Code: OG0-091 Exam Name: TOGAF 9 Part 1 Version: Demo QUESTION 1 According to TOGAF, Which of the following are the architecture domains that are commonly accepted subsets of
More informationThe Open Group SOA Ontology Technical Standard. Clive Hatton
The Open Group SOA Ontology Technical Standard Clive Hatton The Open Group Releases SOA Ontology Standard To Increase SOA Adoption and Success Rates Ontology Fosters Common Understanding of SOA Concepts
More informationUniversal Model Framework -- An Introduction
Universal Model Framework -- An Introduction By Visible Systems Corporation www.visible.com This document provides an introductory description of the Universal Model Framework an overview of its construct
More informationIncorporating applications to a Service Oriented Architecture
Proceedings of the 5th WSEAS Int. Conf. on System Science and Simulation in Engineering, Tenerife, Canary Islands, Spain, December 16-18, 2006 401 Incorporating applications to a Service Oriented Architecture
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationADD 3.0: Rethinking Drivers and Decisions in the Design Process
ADD 3.0: Rethinking Drivers and Decisions in the Design Process Rick Kazman Humberto Cervantes SATURN 2015 Outline Presentation Architectural design and types of drivers The Attribute Driven Design Method
More informationNext-Generation Architecture for Virtual Prototyping
Next-Generation Architecture for Virtual Prototyping Dr. Bipin Chadha John Welsh Principal Member Manager Lockheed Martin ATL Lockheed Martin ATL (609) 338-3865 (609) 338-3865 bchadha@atl.lmco.com jwelsh@atl.lmco.com
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationObjectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture
Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationIntroduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p.
Preface p. xv Introduction to Software Engineering p. 1 The Scope of Software Engineering p. 3 Historical Aspects p. 4 Economic Aspects p. 7 Maintenance Aspects p. 8 Specification and Design Aspects p.
More informationRational Software White paper
Unifying Enterprise Development Teams with the UML Grady Booch Rational Software White paper 1 There is a fundamental paradox at play in contemporary software development. On the one hand, organizations
More informationThe Design Patterns Matrix From Analysis to Implementation
The Design Patterns Matrix From Analysis to Implementation This is an excerpt from Shalloway, Alan and James R. Trott. Design Patterns Explained: A New Perspective for Object-Oriented Design. Addison-Wesley
More informationBUILDING the VIRtUAL enterprise
BUILDING the VIRTUAL ENTERPRISE A Red Hat WHITEPAPER www.redhat.com As an IT shop or business owner, your ability to meet the fluctuating needs of your business while balancing changing priorities, schedules,
More informationFacade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004
Facade and Adapter Comp-303 : Programming Techniques Lecture 19 Alexandre Denault Computer Science McGill University Winter 2004 March 23, 2004 Lecture 19 Comp 303 : Facade and Adapter Page 1 Last lecture...
More informationSOFTWARE LIFE-CYCLE MODELS 2.1
SOFTWARE LIFE-CYCLE MODELS 2.1 Outline Software development in theory and practice Software life-cycle models Comparison of life-cycle models 2.2 Software Development in Theory Ideally, software is developed
More informationAn Expert System for Design Patterns Recognition
IJCSNS International Journal of Computer Science and Network Security, VOL.17 No.1, January 2017 93 An Expert System for Design Patterns Recognition Omar AlSheikSalem 1 and Hazem Qattous 2 1 Department
More informationAn Approach to Software Component Specification
Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationMetrics and OO. SE 3S03 - Tutorial 12. Alicia Marinache. Week of Apr 04, Department of Computer Science McMaster University
and OO OO and OO SE 3S03 - Tutorial 12 Department of Computer Science McMaster University Complexity Lorenz CK Week of Apr 04, 2016 Acknowledgments: The material of these slides is based on [1] (chapter
More informationThe Big Happy Family of System Architecture Approaches. Chris Phillips 14 Jun 2018
The Big Happy Family of System Architecture Approaches Chris Phillips 14 Jun 2018 Agenda Introduction Overview Key Definitions System Architecture Overview Architectural Approaches Integrating Architectural
More informationSOFTWARE ENGINEERING
SOFTWARE ENGINEERING INTRODUCTION TO SOFTWARE ENGINEERING. COURSE STRUCTURE AND REQUIREMENTS Saulius Ragaišis saulius.ragaisis@mif.vu.lt WHAT IS SOFTWARE ENGINEERING? First definition Software engineering
More informationExamples. Object Orientated Analysis and Design. Benjamin Kenwright
Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision
More informationRED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE.
RED HAT ENTERPRISE LINUX. STANDARDIZE & SAVE. Is putting Contact us INTRODUCTION You know the headaches of managing an infrastructure that is stretched to its limit. Too little staff. Too many users. Not
More informationAlignment of Business and IT - ArchiMate. Dr. Barbara Re
Alignment of Business and IT - ArchiMate Dr. Barbara Re What is ArchiMate? ArchiMate is a modelling technique ("language") for describing enterprise architectures. It presents a clear set of concepts within
More informationThe requirements engineering process
3 rd Stage Lecture time: 8:30-12:30 AM Instructor: Ali Kadhum AL-Quraby Lecture No. : 5 Subject: Software Engineering Class room no.: Department of computer science Process activities The four basic process
More informationA Practitioner s Approach to Successfully Implementing Service Virtualization
A Practitioner s Approach to Successfully Implementing Service Virtualization The Final Piece of the Puzzle Gaurish Vijay Hattangadi Executive Summary Service virtualization envisions a promising solution
More information*ANSWERS * **********************************
CS/183/17/SS07 UNIVERSITY OF SURREY BSc Programmes in Computing Level 1 Examination CS183: Systems Analysis and Design Time allowed: 2 hours Spring Semester 2007 Answer ALL questions in Section A and TWO
More informationReview Software Engineering October, 7, Adrian Iftene
Review Software Engineering October, 7, 2013 Adrian Iftene adiftene@info.uaic.ro Software engineering Basics Definition Development models Development activities Requirement analysis Modeling (UML Diagrams)
More informationAdaptive Internet Data Centers
Abstract Adaptive Internet Data Centers Jerome Rolia, Sharad Singhal, Richard Friedrich Hewlett Packard Labs, Palo Alto, CA, USA {jar sharad richf}@hpl.hp.com Trends in Internet infrastructure indicate
More informationJBuilder 2007 Product Tour November 2006
JBuilder 2007 Product Tour November 2006 Introduction... 3 Eclipse Overview... 4 JBuilder 2007 Overview... 4 ProjectAssist. 5 Graphical EJB Workbench... 6 TeamInsight..7 Conclusion... 10 2 Introduction
More informationIT Project Management Challenges with Open Source. George A Pace
IT Project Management Challenges with Open Source George A Pace Tonight s agenda Two parts to the Presentation What is Open Source? A background primer on the key elements of Open Source. A specific focus
More informationDemystifying GRC. Abstract
White Paper Demystifying GRC Abstract Executives globally are highly focused on initiatives around Governance, Risk and Compliance (GRC), to improve upon risk management and regulatory compliances. Over
More informationSoftware Reuse Techniques
DCC / ICEx / UFMG Software Reuse Techniques Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Overview of Reuse Techniques Frameworks Design Patterns Configurable Applications Architecture Patterns
More information