Refining the Structure of the Requirements Model

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

description

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 - PowerPoint PPT Presentation

Transcript of Refining the Structure of the Requirements Model

Page 1: Refining the Structure of the Requirements Model

Refining the Structure of the Requirements Model

Aim: To create the conditions for software re-use.

Bennett, McRobb and Farmer ch 8

Page 2: Refining the Structure of the Requirements Model

Mechanisms for Software Reuse

1. Abstraction mechanisms: generalisation, composition, encapsulation/information hiding

2. Specification of Reusable software components

3. Application of Analysis Patterns

Page 3: Refining the Structure of the Requirements Model

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.

Page 4: Refining the Structure of the Requirements Model

Why Re-Use?

• No need to reinvent the wheel• Enforces standardisation which can make

subsequent change easier

Page 5: Refining the Structure of the Requirements Model

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.

Page 6: Refining the Structure of the Requirements Model

Abstraction mechanisms in OO

1. Generalisation/ Inheritance2. Encapsulation3. Composition

Page 7: Refining the Structure of the Requirements Model

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.

Page 8: Refining the Structure of the Requirements Model

Example- Agate (ch 8) Staffmember

NameNOStart Date

Calculatebonus()AssignNewStaffGrade()getStaffdetails()

AdminStaff

Calculatebonus()

CreativeStaff

qualification

Calculatebonus()Assignstaffcontact()

Page 9: Refining the Structure of the Requirements Model

Example: Sligo MotorhomesVehicle

Serial numberModelYear

Sell()Getdetails()

New Vehicle

NameManufacturerBase Cost

Sell()Chooseoptions()

Trade in vehicle

Make

Sell()

Page 10: Refining the Structure of the Requirements Model

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.

Page 11: Refining the Structure of the Requirements Model

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

Page 12: Refining the Structure of the Requirements Model

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

Page 13: Refining the Structure of the Requirements Model

Example

• A newspaper advert can be composed of copy(text), graphics and a photograph.

GraphicsNewspaperAdvert

Text

Photo

0..* 1..*

1..*

0..*

1..*

1..*

Page 14: Refining the Structure of the Requirements Model

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.

Page 15: Refining the Structure of the Requirements Model

Divide your classes into packages

Page 16: Refining the Structure of the Requirements Model

Example Agate (p246)• Packages mark out related but distinct

application areas: advert preparation, staff management, campaign management.

campaign managemen

tControl

staff management

advert preparation

User Interface

Page 17: Refining the Structure of the Requirements Model

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.

Page 18: Refining the Structure of the Requirements Model

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).

Page 19: Refining the Structure of the Requirements Model

Ball and socket diagram.

Component A Component B

Page 20: Refining the Structure of the Requirements Model

• 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).

Page 21: Refining the Structure of the Requirements Model

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.

Page 22: Refining the Structure of the Requirements Model

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

Page 23: Refining the Structure of the Requirements Model

Service Oriented Architecture

• Designed to enable larger grained components to be integrated together

• Needs clear interface design

• E.g. Web services use

Page 24: Refining the Structure of the Requirements Model

<<component>> Payments <<component>>

Bookings

<<component>> FlightManagement

<<component>> Customers

<<component>> Check-in

makebooking

allocateseatsmanagecustomers

takepayment

allocateseats

From Bennett Mc Robb and Farmer p250

Page 25: Refining the Structure of the Requirements Model

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.

Page 26: Refining the Structure of the Requirements Model

Example

Transaction

Transaction noTransactiondateTransactiontotal

Transactionline

TransactionlinenoTransactionlineqtyTransactionlinevalue

10..*

Bennett, Mc Robb and Farmer p254

Page 27: Refining the Structure of the Requirements Model

• 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.