UNIFACE Component-based. Development Methodology UNIFACE V Revision 0 Dec 2000 UMET

Size: px
Start display at page:

Download "UNIFACE Component-based. Development Methodology UNIFACE V7.2. 151157206-00 Revision 0 Dec 2000 UMET"

Transcription

1 UNIFACE Component-based Development Methodology UNIFACE V Revision 0 Dec 2000 UMET

2 UNIFACE Component-based Development Methodology Revision 0 Restricted Rights Notice This document and the product referenced in it are subject to the following legends: Compuware Corporation. All rights reserved. Unpublished - rights reserved under the Copyright Laws of the United States. U.S. GOVERNMENT RIGHTS-Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in Compuware Corporation license agreement and as provided in DFARS (a) and (a) (1995), DFARS (c)(1)(ii)(OCT 1988), FAR (a) (1995), FAR , or FAR (ALT III), as applicable. Compuware Corporation. This product contains confidential information and trade secrets of Compuware Corporation. Use, disclosure, or reproduction is prohibited without the prior express written permission of Compuware Corporation. Trademarks Compuware is a registered trademark of Compuware Corporation and UNIFACE is a registered trademark of Compuware Europe B.V. CICS, DB2, IBM, and OS/2 are trademarks of International Business Machines Corporation. SOLID Server (TM), SOLID Bonsai Tree (TM), SOLID Remote Control (TM), and SOLID SQL Editor (TM) are trademarks of Solid Information Technology Ltd. All other company or product names used in this publication are trademarks of their respective owners. 24-hour online customer support and learning MyUNIFACE is an Internet-based support and learning environment which provides real-time access to a wealth of UNIFACE product and technical information. Features include online product documentation, technical tips and know-how, up-to-date platform availability, product fixes, course information, online training, and live communication with fellow developers. You can obtain full access privileges for MyUNIFACE by completing an online registration form (customer license information is required) at For the latest version of the documentation always check the UNIFACE Library on the MyUNIFACE site. Your suggestions and comments about UNIFACE documentation and course material are highly valued. Please send your reactions to: Compuware Europe B.V. Delivery Methods & Practices P. O. Box AX Amsterdam The Netherlands fax: +31 (0)

3 Contents 1 Introduction 1.1 Objects and components What is an object? Object structure Object behavior Encapsulation What is a component? Design by Contract Component interfaces Data hiding Why develop component-based applications? Adding new functionality Reusing components Easier maintenance of existing functionality Replacing components with other components Separating application layers Assembly of applications is simplified with components Scalability Why a new component-based modeling technique? Component-based development process 2.1 Inception The Modeling Process Modeling process analysis Business function modeling Object modeling Behavioral modeling UNIFACE Component-based Development Methodology (Dec 2000) iii

4 2.4 Modeling process design Component model design Component design Relational model design Business rule design Inter-component communication design UNIFACE design implementation Development Incremental development approach Incremental development process Prioritizing increments Iterative development approach Prototyping approach Exploratory prototyping Experimental prototyping Quality assurance Testing White box testing Black Box Testing Testing Techniques Deployment Service level management Usability measurement Summary Appendix A Sample use case description iv (Dec 2000)

5 Chapter 1 Introduction Component-based development represents a significant paradigm shift in application development. While component-based development techniques have been used effectively in engineering and manufacturing circles for many years, their application to software development is relatively recent. The techniques came about in response to many of the issues facing IT organizations today: reducing time to market, responding more rapidly to change, and providing the flexibility to change the scale or scope of functionality to keep pace with changes in the business. There are some inherent challenges in applying component-based development techniques to software development. Until now, it has been usual practice to design and build large, monolithic systems that perform very specific functions. Component-based development, however, employs a three-phase approach of modeling reusable, interchangeable components, constructing the components, and assembling them into a complete application. Component-based applications are quite different from those developed in the past, and the process for developing component-based applications is also very different. Therefore, Compuware has developed a new methodology to address the particular demands of component-based development. A software engineering methodology is a process for the organized production of software using a collection of predefined techniques and notation conventions. A methodology is usually presented as a series of steps, with techniques and deliverables associated with each step. The UNIFACE component-based development methodology uses industry-standard object-oriented modeling techniques and notation incorporated in the Unified Modeling Language (UML). This component-based methodology addresses the entire system development life cycle, conceived specifically to deliver the optimum design for component-based applications. To achieve this goal, a thorough UNIFACE Component-based Development Methodology (Dec 2000) 1-1

6 understanding of the internal workings and goals of the business must first be established. UML provides a means to model and communicate an understanding of the business through a standard set of techniques and notations. Ultimately, UML deliverables are used to populate the UNIFACE application models and component models. This methodology embodies the UNIFACE 3D paradigm of component-based development, component-based deployment and component-based delivery. It is designed to provide a high degree of productivity and rapid response to change. Component-based development is divided into the following main activities: Modeling Construction Assembly Figure 1-1 shows the relative effort required in each of the activities during the application development cycle. Modeling (Analysis & Design) Construction Assembly Effort Elapsed time Figure 1-1 Component-based development. UML provides an excellent means to model and communicate an understanding of the business. Before discussing where UML techniques are specifically applied in component-based modeling, refer first to section 1.1 Objects and components. 1-2 (Dec 2000) Introduction

7 The UNIFACE component-based development methodology enhances Compuware s tools for modeling, construction and assembly of component-based applications, and provides a practical methodology for the successful development of large-scale component-based systems. 1.1 Objects and components Before considering the UML techniques applied in modeling, it is important to understand the answers to the following questions: What is an object? What is a component? Why develop component-based applications? Why use a new component-based modeling technique? 1.2 What is an object? An object is a specific, real-world item that you need to keep information about and use in order to conduct your business. For example, a retailer of computer equipment might require objects such as Computer Equipment, Peripheral Devices, Vendors, and Clients to conduct their business. These objects are important to the business, so it is necessary to keep relevant information about them. This information is expressed as the structure and behavior of the objects Object structure The structure of an object is defined as a group of attributes. Attributes are the individual data items that are used to describe an object within the context of the business. For example, the structure of the Computer Equipment object might consist of: Serial Number Model Number Manufacturer UNIFACE Component-based Development Methodology (Dec 2000) 1-3

8 Cost Retail Price The structure defined for an object must be consistent for all occurrences of that object Object behavior The behavior of an object is defined as operations. Operations are the distinct functions performed by an object within the scope of the business. For example, the behavior of the Computer Equipment object can include the following: Order Equipment Receive Equipment Sell Equipment The behavior defined for an object must be consistent for all occurrences of the object Encapsulation From the descriptions in section Object structure and section Object behavior, you might conclude that the object s structure is similar to data specifications, and that the object s behavior is similar to process specifications. This conclusion can be correct. However, prior to the use of object-oriented design techniques, data design and process design were addressed separately. When object-oriented design techniques such as UML are used, there is no separation between structure (data) and behavior (process). The behavior of an object encapsulates its structure. Encapsulation means to enclose or conceal. When the term encapsulation is applied to an object, it means that its structure is enclosed or hidden by its behavior. This technique is often referred to as data hiding. The object s data structure is concealed from the user, and is only accessible by one of its public behaviors. Figure 1-2 illustrates how structure is encapsulated by behavior. 1-4 (Dec 2000) Introduction

9 Order Equipment Receive Equipment Computer Equipment à Serial Number Model Number Manufacturer Cost à Retail Price Sell Equipment Figure 1-2 The computer equipment object s behavior encapsulates its data. Advantages of encapsulation In today s dynamic business environment, frequent changes have become commonplace. Keeping pace with this change is one of the greatest challenges businesses face today. Using the example of a computer equipment retailer, what would happen if the company decided to begin repairing equipment in addition to selling it? They would need to add new information to the structural and behavioral characteristics of the computer equipment object. For example, the attributes Warranty Type and Warranty Length, and a new operation Repair Equipment, would need to be added. Adding this additional data and functionality means that the retailer has to make many extensive changes to existing programs and recompile any programs that deal with computer equipment. With an encapsulated object, however, none of this extra work is necessary. New attributes and behavior can be added without affecting any of the existing behaviors. Figure 1-3 illustrates this: UNIFACE Component-based Development Methodology (Dec 2000) 1-5

10 Order Equipment Receive Equipment à à Computer Equipment Serial Number Model Number Manufacturer Cost Retail Price Warranty Type Warranty Length Repair Equipment Sell Equipment Figure 1-3 Adding a new behavior. 1.3 What is a component? A component is an independently deliverable collection of related software operations that can be used to build applications or larger components. A component can implement a single function, a subsystem, or an entire application. The operations implemented within components correspond to the behaviors specified for the objects. Therefore, components (and their interfaces) provide the means to achieve the encapsulation of the objects. Figure 1-4 shows a simple example of how an operation can be implemented within a component: 1-6 (Dec 2000) Introduction

11 Order Equipment Receive Equipment Computer Equipment à Serial Number Model Number Manufacturer Cost Retail Price à Warranty type Warranty length Repair Equipment Sell Equipment Figure 1-4 Implementing an operation within a component Design by Contract Design by Contract is an essential principle in component-based development, and lays the foundation for the successful design of components. Design by Contract associates a design contract with every component, which is a set of logical assertions. These assertions define the component s contract and consist of the following: Preconditions conditions that must be true before an operation can be executed Business rules functional requirement for each operation Signatures set of input and output parameters for each operation Post conditions output conditions for each operation Invariants global consistency conditions both assumed and maintained by every operation (such as state and context) Based upon the assertions of the contract, the developer using the component can be confident of the integrity of its function and the accuracy of its interface. Also, the following benefits can be derived from Design by Contract: UNIFACE Component-based Development Methodology (Dec 2000) 1-7

12 Development of components that accurately meet the needs of the business A rich source of requirements for component testing A good quality assurance mechanism Automatic documentation of component functions The user of the component need not be concerned with the details of its implementation Applying the principle of Design by Contract requires: Standards for defining component requirements A standard for defining component interfaces Component naming standards Standard testing scripts to ensure the component functions according to its defined requirements A component management function, based upon a repository of the component contracts Component interfaces All components should be accessed via their published interface. Each component is made up of a group of related operations. Each of the operations has a signature. The signature contains the string of data attributes required by the operation to complete its function, as well as the set of attributes the operation returns as output. Operations also have pre-conditions and post-conditions. When a user interacts with a component, they must activate a specific operation within the component and supply all of the input parameters contained within the operation s signature. Prior to the activation of the operation, all pre-conditions must be evaluated and satisfied. All post-conditions are assumed to be true upon the successful completion of the operations. A component interface consists of the collection of user-accessible operations with their pre-conditions and post-conditions. Based on the principle of data hiding, the domain of data that a user can access through any given component is governed by the set of operations made available through the component's public interface. You can access a component s functionality and data by activating an operation and by populating the input parameters of its interface. When the operation completes, the component returns the string of fields or occurrences defined as the output parameters of the interface. 1-8 (Dec 2000) Introduction

13 The definition of published component interfaces can depend on the granularity of the components themselves. Typically, components are quite granular and contain a small group of related operations. However, interfaces can be defined at higher levels for more complex components, such as subsystems, encapsulated legacy applications, or TP monitor transactions. Component interfaces are the mechanism by which component dependencies and links are implemented. They must have a standard format (for more information, see the UNIFACE Component Interface Standards), and should be managed through a component repository (such as the UNIFACE assembly workbench) Data hiding Data hiding means that the component user or client does not actually see or know the implementation details of the data structure as used internally by the component. Instead of writing retrieval procedures or query statements, the available data is accessed via the published interface of the component. In traditional software development, the developer requires detailed knowledge of the underlying structure and storage techniques of an application s data. A major advantage of component-based development is that the component user or client does not require detailed knowledge of its implementation. In other words, to utilize a component, the user only needs to know the published interface. These characteristics should all defined and governed by the design contract for the component. Through the use of data hiding techniques, components can be reused freely without concern for issues such as data retrieval, data storage, or the communication of data between applications. To achieve the benefits of reuse and architectural flexibility offered by data hiding, the application must be separated into distinct presentation, business logic, and data access layers. The desired reuse and architectural flexibility is not realized unless all components function exactly as stated by their design contract. UNIFACE Component-based Development Methodology (Dec 2000) 1-9

14 1.4 Why develop component-based applications? Component-based applications provide the following benefits: The ability to add new functionality without impacting existing functionality. It is easier to maintain existing functionality. You can replace components with other components sharing the same interface. The use of components make it easier to develop and assemble applications. Components can be reused. Presentation, business logic and data access layers of the application are separated. Application scalability is enhanced Adding new functionality Encapsulation makes it possible to add new functionality (behaviors) to applications without impacting the existing functionality. In other words, to add a new function, all that is required is to build the new component, test it, and integrate it into the existing component repository. No program changes or further compilations of other components are necessary Reusing components Components are reusable. This means that once a component is developed, the operations within it can be activated by other components. Consequently, you need to develop an operation only once.if the operation is required by another component or subsystem, it can simply be reused instead of being duplicated or re-created. While reuse can significantly increase the speed and productivity of application development efforts, it is equally important to identify and implement an appropriate reuse strategy for each project. This strategy ensures a balance between component granularity and component function (Dec 2000) Introduction

15 If you develop a number of small components (a small component would be, for example, a component containing a single computation or edit function), the degree of reuse is high. However, assembling an application using such small components can be complex and can adversely affect productivity. Larger, more complex components can result in greater productivity, but offer less opportunity for reuse. Figure 1-5 illustrates the relationship between reuse and productivity based on the granularity of components. Packaged applications Application components, subsystems Objects, controls, class libraries Reuse Business components, subsystems Productivity Figure 1-5 Trade-off between reuse and productivity Easier maintenance of existing functionality When maintaining existing functionality, changes can be made to existing components as long as no changes are made to their interface. Once a component is modified, the component should be thoroughly tested to ensure it still functions as intended, using regression testing or a similar testing regime. After testing, the component should be reintegrated into the application and component repository. No program changes or recompilations of other components are required. You do not need to test any other functionality of the same component. UNIFACE Component-based Development Methodology (Dec 2000) 1-11

16 1.4.4 Replacing components with other components A component is a set of related operations. Each component has its own unique design contract. Based upon the assertions of the contract, a developer using a component can be confident in the integrity of its function and the accuracy of its interface. As components are assembled into applications, interfaces provide the means of linking components together in order to provide the desired functionality. For example, an order entry component might be linked to a part selection component to enable the user to make a selection from a list of available parts when entering an order. As components are self-contained, they can be replaced by other components. For example, the part selection component mentioned above could have been implemented using C++. At some point, you can decide that this function could be better implemented using a different technology, such as UNIFACE. Any component can be replaced at assembly time by another component that fulfills the specified design contract Separating application layers Components allow you to adopt a multitier architecture by making it possible to separate the presentation, business logic, and data access layers of an application. Components within the presentation layer provide the graphical user interface (GUI) and govern the user s interaction with the application. Presentation components contain no business rules and are stateless. Components within the business logic layer realize all of the applications business rules and disclose the public structural and behavior elements to the presentation layer. These business rules include process-based business rules, structural business rules, rules that apply to hierarchical records sets, and rules that apply to specific occurrences or collections of records. Components within the data access layer provide transparent, heterogeneous access to the various application data sources. Primarily, these components consist of DBMS drivers or ODBC drivers. Additionally, there can be other more complex data access components, such as UNIFACE PolyServer or encapsulated DBMS stored procedures (Dec 2000) Introduction

17 There is also another variety of high-level components, called system services components, that reside outside of these three layers. System services components provide functions and services that can be used by all applications residing within the application architecture. These are global functions, such as security, global edits, error handling, and controller objects. Separating the presentation, business logic, and data access layers of the application makes it possible to reuse components, or replace a component by another component. A multitier architecture ensures flexibility in application development, assembly, and deployment. It also provides a great deal of flexibility when distributing components across a wide variety of application architectures, such as the Internet, n-tier or traditional two-tier client/server, mainframes, or a combination of these. A multitier architecture has a major affect on the components designed for an application. The definition of each layer of the architecture, and the functions or services provided by each layer, must be defined as part of the analysis phase. During the design phase, a component model must be established that satisfies all the architectural requirements defined during the analysis phase Assembly of applications is simplified with components Component-based assembly is the process of linking a group of components to form a complete application. The source for these components is not limited to those developed in-house; components can also be used from purchased packages or from legacy systems. As components can be reused, it is no longer necessary to duplicate functionality between applications. In addition, because you only need to know a component s interface in order to use it, there is no need for extensive coding to integrate components Scalability While there are many new applications being built today, many mainframe and client/server legacy applications are still in use. The use of components makes it possible to provide seamless integration between these legacy applications and new, component-based applications. Also, the rapid expansion of the Internet has created new business requirements, such as B2C and B2B e-commerce. Components make it UNIFACE Component-based Development Methodology (Dec 2000) 1-13

18 possible to open up previously closed, in-house systems to customers and business partners over the Internet. These are just a few examples of how the use of components make it possible to flexibly adjust the scale of an application to address factors such as different architectures, varying numbers of users, increased transaction volumes, legacy integration, and e-commerce. 1.5 Why a new component-based modeling technique? Component-based modeling, using industry-standard UML techniques, allows you to create an optimal design for component-based applications. Techniques such as Entity-Relationship Diagrams or Data Flow Diagrams do not adequately express the structure and behavior of objects. These techniques were developed for designing applications made up of sequential processes and hierarchical data structures. UML-based techniques allow for modeling encapsulated business objects that offer all of the previously outlined advantages (Dec 2000) Introduction

19 Chapter 2 Component-based development process Figure 2-1 Component-based development process. Figure 2-1 provides an overview of the component-based development process. This process consists of five basic phases or activities: inception, analysis, design, development and quality assurance. This chapter describes each of these phases and the deliverables resulting from them. UNIFACE Component-based Development Methodology (Dec 2000) 2-1

20 Figure 2-1 also shows that this process is iterative. Components are developed through a number of iterations, or repetitions, of the CBD life cycle: Inception gather business requirements from users and stakeholders Analysis produce and validate UML analysis models from business requirements Design apply the properties of the application architecture to the analysis models to produce the UML design models Development develop components based on the analysis and design models Quality assurance test the functionality, usability, and performance of the components to determine how well the requirements have been met Feedback from the testing become the requirements for the next iteration The first iteration through the CBD process addresses the requirements for all functionality within the scope of the project. At the development phase, application functionality is constructed (see section 2.6 Incremental development approach). Application functionality is divided into increments (discrete portions). Each of these increments consists of a set of independently deployable, reusable components. Thus the development of each increment can proceed independently using iterative development techniques (see section section 2.7 Iterative development approach) to build and refine the increment. 1 Once a development iteration for an increment has been completed, it proceeds into the quality assurance phase where it is thoroughly tested. The feedback from the testing then becomes the initial requirements for the next iteration. Each subsequent iteration is then focussed on satisfying the requirements of a specific increment. This cycle is repeated for each increment a set number of times, or until the stated requirements are satisfied. Incremental development provides a number of advantages, including: Smaller, more manageable development tasks Opportunities for parallel development Fewer risks Improved quality of the components 1. Because the components delivered from each increment are independently deployable, increments can be developed in parallel. 2-2 (Dec 2000) Component-based development process

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53 Preface xvi Part I Introduction and System Engineering 1 Chapter 1 Introduction 2 1.1 What Is Software Engineering? 2 1.2 Why Software Engineering? 3 1.3 Software Life-Cycle Activities 4 1.3.1 Software

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Information Systems Analysis and Design CSC340. 2004 John Mylopoulos. Software Architectures -- 1. Information Systems Analysis and Design CSC340

Information Systems Analysis and Design CSC340. 2004 John Mylopoulos. Software Architectures -- 1. Information Systems Analysis and Design CSC340 XIX. Software Architectures Software Architectures UML Packages Client- vs Peer-to-Peer Horizontal Layers and Vertical Partitions 3-Tier and 4-Tier Architectures The Model-View-Controller Architecture

More information

UML TUTORIALS THE USE CASE MODEL

UML TUTORIALS THE USE CASE MODEL UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

Architectural Design

Architectural Design Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural

More information

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed.

CS 389 Software Engineering. Lecture 2 Chapter 2 Software Processes. Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. CS 389 Software Engineering Lecture 2 Chapter 2 Software Processes Adapted from: Chap 1. Sommerville 9 th ed. Chap 1. Pressman 6 th ed. Topics covered Software process models Process activities Coping

More information

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective:

CS 487. Week 8. Reference: 1. Software engineering, roger s. pressman. Reading: 1. Ian Sommerville, Chapter 3. Objective: CS 487 Week 8 Reading: 1. Ian Sommerville, Chapter 3. Objective: 1. To check the understandibility of the students in life cycle and process model for development of a software product. 2. To check if

More information

zen Platform technical white paper

zen Platform technical white paper zen Platform technical white paper The zen Platform as Strategic Business Platform The increasing use of application servers as standard paradigm for the development of business critical applications meant

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

Chapter 2 Database System Concepts and Architecture

Chapter 2 Database System Concepts and Architecture Chapter 2 Database System Concepts and Architecture Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 2 Outline Data Models, Schemas, and Instances Three-Schema Architecture

More information

Course Registration Case Study

Course Registration Case Study Course Registration Case Study Table of Contents Case Study...1 Case Study Background... 2 Course Registration System Problem Statement... 2 The Role of Tools... 2 Project Summary... 2 The Inception Phase...

More information

Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment 1 2010. Marque Browne 0814547. Manuel Honegger - 0837997

Swirl. Multiplayer Gaming Simplified. CS4512 Systems Analysis and Design. Assignment 1 2010. Marque Browne 0814547. Manuel Honegger - 0837997 1 Swirl Multiplayer Gaming Simplified CS4512 Systems Analysis and Design Assignment 1 2010 Marque Browne 0814547 Manuel Honegger - 0837997 Kieran O' Brien 0866946 2 BLANK MARKING SCHEME 3 TABLE OF CONTENTS

More information

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. System Models. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering System Models Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain why the context of a system should be modeled as part of the RE process To describe

More information

Component Based Development Methods - comparison

Component Based Development Methods - comparison Component Based Development Methods - comparison Dan Laurenţiu Jişa Abstract: This paper realizes a comparison among three of the best known component based development methods, emphazing on the earlier

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0 NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5

More information

Increasing Development Knowledge with EPFC

Increasing Development Knowledge with EPFC The Eclipse Process Framework Composer Increasing Development Knowledge with EPFC Are all your developers on the same page? Are they all using the best practices and the same best practices for agile,

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Developing SOA solutions using IBM SOA Foundation

Developing SOA solutions using IBM SOA Foundation Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Outline. TIM 50 - Business Information Systems. Lecture 10. Instructor: Terry Allen UC Santa Cruz 10/28/2011

Outline. TIM 50 - Business Information Systems. Lecture 10. Instructor: Terry Allen UC Santa Cruz 10/28/2011 TIM 50 - Business Information Systems Lecture 10 Instructor: Terry Allen UC Santa Cruz 10/28/2011 Outline Announcements Review Alibris Case Study Information Technology Student Presentations Client-Server

More information

TIM 50 - Business Information Systems

TIM 50 - Business Information Systems TIM 50 - Business Information Systems Lecture 10 Instructor: Terry Allen UC Santa Cruz 10/28/2011 Outline Announcements Review Alibris Case Study Information Technology Student Presentations Client-Server

More information

Information Systems Development Process (Software Development Life Cycle)

Information Systems Development Process (Software Development Life Cycle) Information Systems Development Process (Software Development Life Cycle) Phase 1 Feasibility Study Concerned with analyzing the benefits and solutions for the identified problem area Includes development

More information

The Role of the Software Architect

The Role of the Software Architect IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation

More information

Software Architecture Document

Software Architecture Document Software Architecture Document Project Management Cell 1.0 1 of 16 Abstract: This is a software architecture document for Project Management(PM ) cell. It identifies and explains important architectural

More information

(BA122) Software Engineer s Workshop (SEW)

(BA122) Software Engineer s Workshop (SEW) Training for the Business Analyst (BA122) Software Engineer s Workshop (SEW) Duration: 4 days CDUs (Continuing Development Units): 28 Description: A practical workshop covering the role of the Business-Systems

More information

General Problem Solving Model. Software Development Methodology. Chapter 2A

General Problem Solving Model. Software Development Methodology. Chapter 2A General Problem Solving Model Software Development Methodology These focus on understanding what the problem is about Chapter 2A Concerned with understanding more about the nature of the problem and possible

More information

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3

Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 Component-based Development Process and Component Lifecycle Ivica Crnkovic 1, Stig Larsson 2, Michel Chaudron 3 1 Mälardalen University, Västerås, Sweden, ivica.crnkovic@mdh.se 2 ABB Corporate Research,

More information

Using UML Part Two Behavioral Modeling Diagrams

Using UML Part Two Behavioral Modeling Diagrams UML Tutorials Using UML Part Two Behavioral Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

Enterprise Architecture: Practical Guide to Logical Architecture

Enterprise Architecture: Practical Guide to Logical Architecture Objecteering Practical Guides Enterprise Architecture: Practical Guide to Logical Architecture Author: Version: 1.0 Copyright: Softeam Softeam Consulting Team Supervised by Philippe Desfray Softeam 21

More information

UML-based Test Generation and Execution

UML-based Test Generation and Execution UML-based Test Generation and Execution Jean Hartmann, Marlon Vieira, Herb Foster, Axel Ruder Siemens Corporate Research, Inc. 755 College Road East Princeton NJ 08540, USA jeanhartmann@siemens.com ABSTRACT

More information

Driving Your Business Forward with Application Life-cycle Management (ALM)

Driving Your Business Forward with Application Life-cycle Management (ALM) Driving Your Business Forward with Application Life-cycle Management (ALM) Published: August 2007 Executive Summary Business and technology executives, including CTOs, CIOs, and IT managers, are being

More information

Software Development in the Large!

Software Development in the Large! Software Development in the Large! Peter Eeles Executive IT Architect, IBM peter.eeles@uk.ibm.com IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development

More information

VAIL-Plant Asset Integrity Management System. Software Development Process

VAIL-Plant Asset Integrity Management System. Software Development Process VAIL-Plant Asset Integrity Management System Software Development Process Document Number: VAIL/SDP/2008/008 Engineering For a Safer World P u b l i c Approved by : Ijaz Ul Karim Rao Revision: 0 Page:2-of-15

More information

A Monitored Student Testing Application Using Cloud Computing

A Monitored Student Testing Application Using Cloud Computing A Monitored Student Testing Application Using Cloud Computing R. Mullapudi and G. Hsieh Department of Computer Science, Norfolk State University, Norfolk, Virginia, USA r.mullapudi@spartans.nsu.edu, ghsieh@nsu.edu

More information

Meta-Model specification V2 D602.012

Meta-Model specification V2 D602.012 PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR

More information

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones.

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones. E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones Introduction E-Commerce Supply Chain Management involves the co-ordination

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Purpose The purpose of this document is to provide guidance on the practice of Modeling and to describe the practice overview, requirements, best practices, activities, and key terms related to these requirements.

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical

More information

Object Oriented System Development with VB.NET

Object Oriented System Development with VB.NET Chapter 1 Object Oriented System Development with Objectives In this chapter, you will: Learn about OO development and Understand object-oriented concepts Recognize the benefits of OO development Preview

More information

3SL. Requirements Definition and Management Using Cradle

3SL. Requirements Definition and Management Using Cradle 3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification

More information

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1

Design with Reuse. Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Design with Reuse Building software from reusable components. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 14 Slide 1 Objectives To explain the benefits of software reuse and some reuse

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

The Open Group Architectural Framework

The Open Group Architectural Framework The Open Group Architectural Framework Background TOGAF is a step-by-step method for developing an enterprise architecture, using a set of prescribed tools. It is freely available on the Open Group website

More information

Unit 1 Learning Objectives

Unit 1 Learning Objectives Fundamentals: Software Engineering Dr. Rami Bahsoon School of Computer Science The University Of Birmingham r.bahsoon@cs.bham.ac.uk www.cs.bham.ac.uk/~rzb Office 112 Y9- Computer Science Unit 1. Introduction

More information

Domain modeling: Leveraging the heart of RUP for straight through processing

Domain modeling: Leveraging the heart of RUP for straight through processing Copyright Rational Software 2003 http://www.therationaledge.com/content/jun_03/t_domainmodeling_rm.jsp Domain modeling: Leveraging the heart of RUP for straight through processing by Richard Menard Vice

More information

WebSphere Business Modeler

WebSphere Business Modeler Discovering the Value of SOA WebSphere Process Integration WebSphere Business Modeler Workshop SOA on your terms and our expertise Soudabeh Javadi Consulting Technical Sales Support WebSphere Process Integration

More information

An Oracle White Paper October 2013. Oracle Data Integrator 12c New Features Overview

An Oracle White Paper October 2013. Oracle Data Integrator 12c New Features Overview An Oracle White Paper October 2013 Oracle Data Integrator 12c Disclaimer This document is for informational purposes. It is not a commitment to deliver any material, code, or functionality, and should

More information

SysML Modelling Language explained

SysML Modelling Language explained Date: 7 th October 2010 Author: Guillaume FINANCE, Objet Direct Analyst & Consultant UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling

More information

Software testing. Objectives

Software testing. Objectives Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating

More information

Software Development Methodologies

Software Development Methodologies Software Development Methodologies Lecturer: Raman Ramsin Lecture 5 Integrated Object-Oriented Methodologies: OPM and Catalysis 1 Object Process Methodology (OPM) Introduced by Dori in 1995 Primarily intended

More information

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java 4.1 Domain Analysis Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing The process by which a software engineer learns about the domain to better

More information

IBM WebSphere Operational Decision Management Improve business outcomes with real-time, intelligent decision automation

IBM WebSphere Operational Decision Management Improve business outcomes with real-time, intelligent decision automation Solution Brief IBM WebSphere Operational Decision Management Improve business outcomes with real-time, intelligent decision automation Highlights Simplify decision governance and visibility with a unified

More information

Tutorial on Client-Server Architecture

Tutorial on Client-Server Architecture Tutorial on Client-Server Architecture SEEM3430 Information Systems Analysis and Design Pengfei Liu Department of Systems Engineering and Engineering Management The Chinese University of Hong Kong March

More information

Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila

Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Application Architectures Ref: Chapter 13 Software Engineering By Ian Sommerville, 7th Edition

More information

Chapter 8 Approaches to System Development

Chapter 8 Approaches to System Development Systems Analysis and Design in a Changing World, sixth edition 8-1 Chapter 8 Approaches to System Development Table of Contents Chapter Overview Learning Objectives Notes on Opening Case and EOC Cases

More information

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice In this Lecture you will Learn: Development Chapter 5C About the Unified Software Development How phases relate to workflows in an iterative life cycle An approach to system development Major activities

More information

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT

A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT A SYSTEMATIC APPROACH FOR COMPONENT-BASED SOFTWARE DEVELOPMENT Cléver Ricardo Guareis de Farias, Marten van Sinderen and Luís Ferreira Pires Centre for Telematics and Information Technology (CTIT) PO Box

More information

Unit I Page No. 1 System Development Object Basics Development Life Cycle Methodologies Patterns Frameworks Unified Approach UML

Unit I Page No. 1 System Development Object Basics Development Life Cycle Methodologies Patterns Frameworks Unified Approach UML Unit I Page No. 1 System Development Object Basics Development Life Cycle Methodologies Patterns Frameworks Unified Approach UML System Development (SD) : - o SD refers to all activities that go into producing

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline

More information

Background: Business Value of Enterprise Architecture TOGAF Architectures and the Business Services Architecture

Background: Business Value of Enterprise Architecture TOGAF Architectures and the Business Services Architecture Business Business Services Services and Enterprise and Enterprise This Workshop Two parts Background: Business Value of Enterprise TOGAF s and the Business Services We will use the key steps, methods and

More information

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change?

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change? MANAGING THE DIGITAL FIRM, 12 TH EDITION Learning Objectives Chapter 13 BUILDING INFORMATION SYSTEMS VIDEO CASES Case 1: IBM: Business Process Management in a Service Oriented Architecture and Managing

More information

How to Plan and Design for Case Management Projects with EMC Documentum xcp

How to Plan and Design for Case Management Projects with EMC Documentum xcp How to Plan and Design for Case Management Projects with EMC Documentum xcp Best Practices Planning Abstract This white paper discusses the EMC Documentum xcelerated Composition Platform and its value

More information

What Is the Java TM 2 Platform, Enterprise Edition?

What Is the Java TM 2 Platform, Enterprise Edition? Page 1 de 9 What Is the Java TM 2 Platform, Enterprise Edition? This document provides an introduction to the features and benefits of the Java 2 platform, Enterprise Edition. Overview Enterprises today

More information

Software Design and Class Diagrams

Software Design and Class Diagrams Software Design and Class Diagrams Massimo Felici Software Design 1 The SEOC course is concerned with software design in terms of objects and components, in particular, object-oriented design Object-oriented

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Definition of a Software Component and Its Elements

Definition of a Software Component and Its Elements I' Chapter 1 Definition of a Software Component and Its Elements Bill Councill George T. Heineman 1.1 Introduction The goal of this chapter is to rigorously define terms that describe the best practices

More information

Surveying and evaluating tools for managing processes for software intensive systems

Surveying and evaluating tools for managing processes for software intensive systems Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Client/server is a network architecture that divides functions into client and server

Client/server is a network architecture that divides functions into client and server Page 1 A. Title Client/Server Technology B. Introduction Client/server is a network architecture that divides functions into client and server subsystems, with standard communication methods to facilitate

More information

Tips for writing good use cases.

Tips for writing good use cases. Transforming software and systems delivery White paper May 2008 Tips for writing good use cases. James Heumann, Requirements Evangelist, IBM Rational Software Page 2 Contents 2 Introduction 2 Understanding

More information

White Paper What Solutions Architects Should Know About The TOGAF ADM

White Paper What Solutions Architects Should Know About The TOGAF ADM White Paper What Solutions Architects Should Know About The TOGAF ADM WP0015 October 2011 The Open Group Architecture Framework 1 (TOGAF) is the most widely referenced architecture framework currently

More information

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The

More information

Uniface Education Directory

Uniface Education Directory Uniface Education Directory Training with Uniface Welcome to the Uniface Education Digest. This document provides details of what training is available, where to find information on schedules and how to

More information

Diagram. Microsoft Dynamics Sure Step Methodology

Diagram. Microsoft Dynamics Sure Step Methodology Diagram Microsoft Dynamics Sure Step Methodology Designed to enable you to better serve your customers by helping reduce their Microsoft Dynamics total cost of ownership, the Sure Step Methodology can

More information

Section C. Requirements Elicitation

Section C. Requirements Elicitation This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike License. Your use of this material constitutes acceptance of that license and the conditions of use of materials on this

More information

The Recipe for Sarbanes-Oxley Compliance using Microsoft s SharePoint 2010 platform

The Recipe for Sarbanes-Oxley Compliance using Microsoft s SharePoint 2010 platform The Recipe for Sarbanes-Oxley Compliance using Microsoft s SharePoint 2010 platform Technical Discussion David Churchill CEO DraftPoint Inc. The information contained in this document represents the current

More information

TIBCO Spotfire and S+ Product Family

TIBCO Spotfire and S+ Product Family TIBCO Spotfire and S+ Product Family Compliance with 21 CFR Part 11, GxP and Related Software Validation Issues The Code of Federal Regulations Title 21 Part 11 is a significant regulatory requirement

More information

Designing Real-Time and Embedded Systems with the COMET/UML method

Designing Real-Time and Embedded Systems with the COMET/UML method By Hassan Gomaa, Department of Information and Software Engineering, George Mason University. Designing Real-Time and Embedded Systems with the COMET/UML method Most object-oriented analysis and design

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

Service Oriented Architectures Using DoDAF1

Service Oriented Architectures Using DoDAF1 1 Service Oriented Architectures Using DoDAF1 Huei-Wan Ang, Fatma Dandashi, Michael McFarren The Mitre Corporation The MITRE Corp. 7515 Colshire Dr. McLean, VA 22102 hwang(at)mitre.org, dandashi(at)mitre.org,

More information

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents

Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe. Table of Contents. A. Short Table of Contents Fundamentals of Database Systems, 4 th Edition By Ramez Elmasri and Shamkant Navathe Table of Contents A. Short Table of Contents (This Includes part and chapter titles only) PART 1: INTRODUCTION AND CONCEPTUAL

More information

Systems analysis is the dissection of a system into its component pieces to study how those component pieces interact and work.

Systems analysis is the dissection of a system into its component pieces to study how those component pieces interact and work. SYSTEMS ANALYSIS Systems analysis is the dissection of a system into its component pieces to study how those component pieces interact and work. We do a systems analysis to subsequently perform a systems

More information

White Paper BMC Remedy Action Request System Security

White Paper BMC Remedy Action Request System Security White Paper BMC Remedy Action Request System Security June 2008 www.bmc.com Contacting BMC Software You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information

More information

Custom Software Development Approach

Custom Software Development Approach Custom Software Development Approach Our approach to custom software development combines benefits from several standard development process models. We tend to have a well-defined, predictable and highly

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Analysis of the Specifics for a Business Rules Engine Based Projects

Analysis of the Specifics for a Business Rules Engine Based Projects Analysis of the Specifics for a Business Rules Engine Based Projects By Dmitri Ilkaev and Dan Meenan Introduction In recent years business rules engines (BRE) have become a key component in almost every

More information

PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY

PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY PARCC TECHNOLOGY ARCHITECTURE ARCHITECTURAL PRINCIPLES AND CONSTRAINTS SUMMARY Version 1.1 November 5, 2012 Architectural Principles and Constraints Summary REVISION HISTORY The following revision chart

More information

Service-Oriented Architecture and Software Engineering

Service-Oriented Architecture and Software Engineering -Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based

More information

Elite: A New Component-Based Software Development Model

Elite: A New Component-Based Software Development Model Elite: A New Component-Based Software Development Model Lata Nautiyal Umesh Kumar Tiwari Sushil Chandra Dimri Shivani Bahuguna Assistant Professor- Assistant Professor- Professor- Assistant Professor-

More information

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g Systems Integration: Component-based software engineering Objectives To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components

More information

Chapter 1 Introduction to Enterprise Software

Chapter 1 Introduction to Enterprise Software Chapter 1 Introduction to Enterprise Software What Is Enterprise Software? Evolution of Enterprise Software Enterprise Software and Component-Based Software Summary If you have heard of terms such as

More information

A Methodology for the Development of New Telecommunications Services

A Methodology for the Development of New Telecommunications Services A Methodology for the Development of New Telecommunications Services DIONISIS X. ADAMOPOULOS Centre for Communication Systems Research School of Elec. Eng., IT and Mathematics University of Surrey Guildford

More information

Data Model ing Essentials

Data Model ing Essentials Data Model ing Essentials Third Edition Graeme C. Simsion and Graham C. Witt MORGAN KAUFMANN PUBLISHERS AN IMPRINT OF ELSEVIER AMSTERDAM BOSTON LONDON NEW YORK OXFORD PARIS SAN DIEGO SAN FRANCISCO SINGAPORE

More information

Managing IT Projects. Chapter 3 Software Project Life cycle

Managing IT Projects. Chapter 3 Software Project Life cycle Managing IT Projects Chapter 3 Software Project Life cycle The Systems Development Life Cycle (SDLC) The SDLC is composed of four fundamental phases: -Planning Analysis Design Implementation The Systems

More information