Refining the Structure of the Requirements Model Aim: To create the conditions for software re-use. Bennett, McRobb and Farmer ch 8.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
IMS1805 Systems Analysis Topic 3: Doing Analysis (continued from previous weeks)
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
2-1 © Prentice Hall, 2007 Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph.
Revision Session 4 Systems and Software Design. Software Design-related Topics What are the key characteristics of a quality software design and how can.
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
03/12/2001 © Bennett, McRobb and Farmer 2002 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
COMP1007 Intro to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Intro to Requirements Analysis Object Oriented.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Revision Session 3 Adding the detail and design for re-use.
Lecture 11: Chapter 22 Topics –Object Oriented Modeling –UML –Use case.
Documenting Requirements using Use Case Diagrams
Requirements Analysis 9. 1 OO Concepts b509.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Object.
UML and the Software Lifecycle
Data and Process Modeling
Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Chapter 8 Object Design Reuse and Patterns. Finding Objects The hardest problems in object-oriented system development are: –Identifying objects –Decomposing.
Reuse Activities Selecting Design Patterns and Components
Implementation classes and developing relational databases IS Development Lecture 9.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
UML and Object Oriented Concepts
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Introduction To System Analysis and design
Refining the Requirements Model
Object Oriented Software Development
Copyright © 2002, Systems and Computer Engineering, Carleton University Intro.ppt * Object-Oriented Software Development Unit 1 Course.
Chapter 13 Starting Design: Logical Architecture and UML Package Diagrams.
Design Patterns OOD. Course topics Design Principles UML –Class Diagrams –Sequence Diagrams Design Patterns C#,.NET (all the course examples) Design Principles.
Objects and Components. The adaptive organization The competitive environment of businesses continuously changing, and the pace of that change is increasing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
System models Abstract descriptions of systems whose requirements are being analysed Abstract descriptions of systems whose requirements are being analysed.
1 CS 456 Software Engineering. 2 Contents 3 Chapter 1: Introduction.
University of Toronto at Scarborough © Bennett, McRobb and Farmer 2005 CSCC40 classes 1 Use CasesUse Case Model Campaign Management PackageModelSub-system.
An Introduction to Software Architecture
Introduction To System Analysis and Design
Odyssey A Reuse Environment based on Domain Models Prepared By: Mahmud Gabareen Eliad Cohen.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
System models l Abstract descriptions of systems whose requirements are being analysed.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
03/12/2001 © Bennett, McRobb and Farmer 2005 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
03/12/2001 © Bennett, McRobb and Farmer 2002 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
Part VII: Design Continuous
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
1 OO Analysis & Design - Introduction to main ideas in OO Analysis & design - Practical experience in applying ideas.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
1 Software Design Lecture What’s Design It’s a representation of something that is to be built. i.e. design  implementation.
Chapter 19: Interfaces and Components [Arlow and Neustadt, 2005] University of Nevada, Reno Department of Computer Science & Engineering.
Chapter 2: Introduction to Object Orientation Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey A.
1 Here are some quotations to get an overview of the kinds of issues of interest.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
Basic Characteristics of Object-Oriented Systems
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Object-Oriented Analysis and Design
Component Based Software Engineering
Abstract descriptions of systems whose requirements are being analysed
Starting Design: Logical Architecture and UML Package Diagrams
SYS466 Domain Classes – Part 1.
Object Oriented Analysis and Design
Refining the Requirements Model
From Use Cases to Implementation
Presentation transcript:

Refining the Structure of the Requirements Model Aim: To create the conditions for software re-use. Bennett, McRobb and Farmer ch 8

Mechanisms for Software Reuse 1. Abstraction mechanisms: generalisation, composition, encapsulation/information hiding 2. Specification of Reusable software components 3. Application of Analysis Patterns

Approaches to Re-Use Import existing components or structures from beyond the project boundaries (e.g. re- use of platform-specific components e.g..Net). Reuse components of current project- identify existing or design with re-use in mind. Design new components for use within other projects.

Why Re-Use? No need to reinvent the wheel Enforces standardisation which can make subsequent change easier

How to re-use 1. The starting point for reuse opportunities is within requirements analysis. Refinement is done through : (i) abstracting common elements i.e. identifying where you can use generalisation/inheritance) and (ii) the encapsulation of composite structures and components.

Abstraction mechanisms in OO 1. Generalisation/ Inheritance 2. Encapsulation 3. Composition

1. Inheritance/generalisation identifying those aspects of a design that are relevant to more than one situation and redesigning your classes to put the common aspects in a parent class and the specific aspects in a child class. Abstract classes are parent classes which have no members in themselves but specify common aspects of a number of (concrete) child classes which can be reused easily. ISA –IS A KIND OF is the key relationship here.

Example- Agate (ch 8) Staffmember Name NO Start Date Calculatebonus() AssignNewStaffGrade() getStaffdetails() AdminStaff Calculatebonus() CreativeStaff qualification Calculatebonus() Assignstaffcontact()

Example: Sligo Motorhomes Vehicle Serial number Model Year Sell() Getdetails() New Vehicle Name Manufacturer Base Cost Sell() Chooseoptions() Trade in vehicle Make Sell()

2. Encapsulation design software that can be used as a black box component. To use it you only need to know how the interface works – not the implementation. This means that you can have different implementations for the same interface, which could be useful, for example in porting an application to different platforms. The focus is on the external behaviour, but ignoring the detail of how that behaviour is produced.

Example : C# libraries We don’t know the implementation of window, textbox.. or any of the other hundreds of classes in WPF, Windows forms etc. BUT We know their interface so we can use them

3. Composition involves encapsulating a group of classes that have the capacity to be a re-usable subassembly. The relationship here is ISA Part Of. Composition – is made up of... A car has an engine Aggregation- can have 0 or more – sand grains on the beach

Example A newspaper advert can be composed of copy(text), graphics and a photograph. Graphics NewspaperAdvert Text Photo 0..*1..* 0..* 1..*

Packages and Dependencies The aim here is to ensure the system remains robust in the face of changing requirements. Organise classes into packages in such a way that change is localised. Show dependencies between these packages e.g. if a class in one package uses or is related to an object in another package this must be shown in the package diagram.

Divide your classes into packages

Example Agate (p246) Packages mark out related but distinct application areas: advert preparation, staff management, campaign management. campaign management Control staff management advert preparation User Interface

Components Relatively complex structures developed separately to be plugged together. Meet a clear-cut but general need. Have more than 1 simple well-defined external interfaces.

UML Support for Modelling Components Component A has a provided interface which offers services to components that know how to request those services. Component B has a required interface which requests services from a provided interface on another component. (basically it will send a message using a defined operation and parameters frpm some provided interface).

Ball and socket diagram. Component AComponent B

In UML, a component diagram provides a physical view of the system. Its purpose is to show the dependencies that the software has on the other software components (e.g., software libraries) in the system. The diagram can be shown at a very high level, with just the large-grain components, or it can be shown at the component package level i.e. class container levels such as.NET's namespaces (e.g., System.Web.UI).

Component-Based Development The classes that comprise an individual component need to be identified, modelled, specified designed and coded. Components must be designed to a common standard e.g. – A component’s behaviour is described by its specification. – A specification can have many implementations e.g. to work on many platforms.

Example: Airline Booking System In airline systems there is often a mix of systems, including older systems and other different systems trying to do the same things. Systems need to be designed to enable the upgrading of older systems with minimum fuss and to enable the use of different types of booking process. A Bookings component provides an interface called makebooking which is available to any system who knows how to use it i.e. knows the services provided and their protocols or signatures

Service Oriented Architecture Designed to enable larger grained components to be integrated together Needs clear interface design E.g. Web services use

> Payments > Bookings > FlightManagement > Customers > Check-in makebooking allocateseats managecustomers takepayment allocateseats From Bennett Mc Robb and Farmer p250

Software Development Patterns A pattern is a template of an example worth copying. Analysis patterns provide a structure of classes and associations that occur again and again. Each pattern can be used to communicate a general understanding about how to model a particular set of requirements.

Example Transaction Transaction no Transactiondate Transactiontotal Transactionline Transactionlineno Transactionlineqty Transactionlinevalue 1 0..* Bennett, Mc Robb and Farmer p254

Software components can reduce the effort in coding and implementation. Analysis components and patterns can reduce the time taken to develop and test a design and also act as a store of knowledge that embodies best practice. They can also reduce the time taken to develop a deep understanding of the system.