03/12/2001 © Bennett, McRobb and Farmer 2005 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.

Slides:



Advertisements
Similar presentations
© 2010 Bennett, McRobb and Farmer1 Use Case Description Supplementary material to support Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Advertisements

© 2010 Bennett, McRobb and Farmer1 Requirements Analysis 1: Requirements and Classes Based on Chapter 7 of Bennett, McRobb and Farmer: Object Oriented.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System modeling 2.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
03/12/2001 © Bennett, McRobb and Farmer Class Design Based on Chapter 14 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
03/12/2001 © Bennett, McRobb and Farmer 2002 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
COMP1007 Intro to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Intro to Requirements Analysis Object Oriented.
Refining the Structure of the Requirements Model Aim: To create the conditions for software re-use. Bennett, McRobb and Farmer ch 8.
Essentials of interaction diagrams Lecture Outline Collaborations Interaction on collaboration diagrams Sequence diagrams Messages from an object.
Requirements Analysis 15.1 Specialised Associations b515.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis.
03/12/2001 © Bennett, McRobb and Farmer Modelling Concepts Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Requirements Analysis 9. 1 OO Concepts b509.ppt © Copyright De Montfort University 2000 All Rights Reserved INFO2005 Requirements Analysis Object.
Data and Process Modeling
Requirements Analysis
03/12/2001 © Bennett, McRobb and Farmer Activity Diagrams Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
03/12/2001 © Bennett, McRobb and Farmer Development Process Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
03/12/2001 © Bennett, McRobb and Farmer What Is Object-Orientation? Based on Chapter 4 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Chapter 8 Object Design Reuse and Patterns. Finding Objects The hardest problems in object-oriented system development are: –Identifying objects –Decomposing.
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Design Patterns Ref : Chapter 15 Bennett et al. useful groups of collaborating classes that provide a solution to commonly occuring problems. provide.
1 © Bennett, McRobb and Farmer 2002, and De Montfort University 2002 Systems Development Methodologies Based on Chapter 22 of Bennett, McRobb and Farmer:
PRJ566: PROJECT PLANNING AND MANAGEMENT Class Diagrams.
IS0514Slide 1 IS0517 Lecture Week 8 Class Diagrams III.
Refining the Requirements Model
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
University of Toronto at Scarborough © Bennett, McRobb and Farmer 2005 CSCC40 classes 1 Use CasesUse Case Model Campaign Management PackageModelSub-system.
Software Development Processes
WXGC6102: Object-Oriented Techniques Refining the Requirements Model References: Chapter 7 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
What Is Object-Orientation?
Object Oriented Analysis & Design & UML (Unified Modeling Language)1 Part V: Design The Design Workflow Design Classes Refining Analysis Relationships.
1 WXGC6102: Object-Oriented Techniques Modelling Concepts References: Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Presented by: CHAN LAI SAN ( ) REBAH DAW SARREB ( ) FIDA AL-OBAISI ( ) 08 April 2008 (Tuesday 6pm – 7:30pm)
1 Object orientation. 2 What benefits does OO give? Primarily –Encapsulation (Associates data & operations) –Types & specialisation –Software re-use.
©Ian Sommerville 1995/2000 (Modified by Spiros Mancoridis 1999) Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions.
CSC 395 – Software Engineering Lecture 12: Reusability –or– Programming was Bjarne Again.
Creational Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Software Architecture in Practice Architectural description (The reduced version)
A Reference Model for Event Patterns Christian Silberbauer
Systems Analysis and Design in a Changing World, 6th Edition 1 Chapter 4 - Domain Classes.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
© Bennett, McRobb and Farmer Requirements Analysis Based on Chapter 7 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
GRASP: Designing Objects with Responsibilities
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
Chapter 16 Applying UML and Patterns Craig Larman
03/12/2001 © Bennett, McRobb and Farmer 2002 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems.
© 2010 Bennett, McRobb and Farmer1 Development Process Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using.
© 2010 Bennett, McRobb and Farmer1 Requirements Analysis 2: Realizing Use Cases Based on Chapter 7 of Bennett, McRobb and Farmer: Object Oriented Systems.
OBJECT ORIENTED AND FUNCTION ORIENTED DESIGN 1 Chapter 6.
03/12/2001 © Bennett, McRobb and Farmer Modelling Concepts Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Domain Classes – Part 1.  Analyze Requirements as per Use Case Model  Domain Model (Conceptual Class Diagram)  Interaction (Sequence) Diagrams  System.
IM 2042 – Information Systems Modeling and Design Topic 4 – Refining the Requirements Model. Design Patterns Based on chapters 8 and 15 of Bennett, McRobb.
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Software Design Patterns in Test Automation
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
DOMAIN CLASSES – PART 1 BTS430 Systems Analysis and Design using UML.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
GRASP – Designing Objects with Responsibilities
Modelling Concepts Based on Chapter 5 Bennett, McRobb and Farmer
CSE 303 – Software Design and Architecture
SYS466 Domain Classes – Part 1.
What Is Object-Orientation?
Systems Analysis and Design I
Systems Analysis and Design I
Refining the Requirements Model
Presentation transcript:

03/12/2001 © Bennett, McRobb and Farmer 2005 Refining the Requirements Model Based on Chapter 8 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (3 rd Edition), McGraw Hill, 2005.

© Bennett, McRobb and Farmer In This Lecture You Will Learn: n About reuse in software development; n How object-orientation contributes to reuse; n How to identify and model aggregation, composition and generalisation; n An approach to modelling components; n About ‘patterns’ in software development; n How analysis patterns help to structure a model.

© Bennett, McRobb and Farmer 2005 n Software development has concentrated on inventing new solutions n Recently, the emphasis has shifted n Much software is now assembled from components that already exist n Component reuse can save money, time and effort Reuse in Software Development

© Bennett, McRobb and Farmer 2005 Reuse in Software Development n Achieving reuse is still hard –Reuse is not always appropriate – can’t assume an existing component meets a new need –Poor model organisation makes it hard to identify suitable components –The NIH (Not-Invented-Here) syndrome –Requirements and designs are more difficult to reuse than code

© Bennett, McRobb and Farmer 2005 Reuse: The Contribution of OO n Encapsulation makes components easier to use in systems for which they were not originally designed n Aggregation and composition can be used to encapsulate components n Generalisation allows the creation of new specialised classes when needed

© Bennett, McRobb and Farmer 2005 Aggregation and Composition n Special types of association, both sometimes called whole-part n A campaign is made up of adverts: Campaign Advert 0..*1 Unfilled diamond signifies aggregation

© Bennett, McRobb and Farmer 2005 n Aggregation is essentially any whole- part relationship n Semantics can be very imprecise n Composition is ‘stronger’: –Each part may belong to only one whole at a time –When the whole is destroyed, so are all its parts Aggregation and Composition

© Bennett, McRobb and Farmer 2005 n An everyday example: n Clearly not composition: –Students could be in several classes –If class is cancelled, students are not destroyed! Class Student 0..*1..* Aggregation and Composition

© Bennett, McRobb and Farmer 2005 n Another everyday example: n This is (probably) composition: –Ingredient is in only one meal at a time –If you drop your dinner on the floor, you probably lose the ingredients too Meal Ingredient 1..*1 Filled diamond signifies composition Aggregation and Composition

© Bennett, McRobb and Farmer 2005 Adding Generalisation Structure n Add generalisation structures when: –Two classes are similar in most details, but differ in some respects –May differ: n In behaviour (operations or methods) n In data (attributes) n In associations with other classes

© Bennett, McRobb and Farmer 2005 Adding Structure n Two types of staff: Have qualifications recorded Can be client contact for campaign Bonus based on campaigns they have worked on Creative Admin Qualifications are not recorded Not associated with campaigns Bonus not based on campaign profits

© Bennett, McRobb and Farmer 2005 Adding Structure: calculateBonus ( ) StaffMember {abstract} staffName staffNo staffStartDate calculateBonus ( ) assignNewStaffGrade ( ) getStaffDetails ( ) CreativeStaff qualification assignStaffContact ( ) AdminStaff calculateBonus ( )

© Bennett, McRobb and Farmer 2005 n Standard UML techniques can be used to model components n Component internals can be detailed in a class diagram n Component interaction can be shown in a communication diagram Modelling Components in UML

© Bennett, McRobb and Farmer 2005 Modelling Components in UML n UML has icons for modelling components in structure diagrams (e.g. class diagrams) « component » Payments TakePayment « component » Bookings Provided interface offers servicesRequired interface uses services Ball-and-socket connector maps provided interface of one component to required interface of another

© Bennett, McRobb and Farmer 2005 Modelling Components in UML n Structure diagrams can mix component icons with other icons, e.g. interfaces «interface» Allocate Seats GetFreeSeats(seatType) AllocateSeat(seatRef) DeallocateSeat(seatRef) Flight Management «component» «realize»

© Bennett, McRobb and Farmer 2005 Software Development Patterns A pattern: n “describes a problem which occurs over and over again in our environment, and then describes the core of a solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” Alexander et al. (1977)

© Bennett, McRobb and Farmer 2005 Software Development Patterns n A pattern has: –A context = a set of circumstances or preconditions for the problem to occur –Forces = the issues that must be addressed –A software configuration that resolves the forces

© Bennett, McRobb and Farmer 2005 Software Development Patterns n Patterns are found at many points in the systems development lifecycle: –Analysis patterns are groups of concepts useful in modelling requirements –Architectural patterns describe the structure of major components of a software system –Design patterns describe the structure and interaction of smaller software components

© Bennett, McRobb and Farmer 2005 Software Development Patterns n Patterns have been applied widely in software development: –Organisation patterns describe structures, roles and interactions in the software development organisation itself n Anti-patterns document bad practice –Mushroom Management is an organisation anti-pattern

© Bennett, McRobb and Farmer 2005 Simple Analysis Pattern Transaction transactionNumber transactionDate transactionTotal updateTransactionTotal ( ) TransactionLineItem TransactionLineNumber transactionLineQuantity transactionLineValue comprises *1

© Bennett, McRobb and Farmer 2005 Accountability Analysis Pattern AccountabilityType Accountability Time Period Party Person Organization commissioner responsible ** * * 1

© Bennett, McRobb and Farmer 2005 Summary In this lecture you have learned about: n How to identify and model aggregation, composition and generalisation n Reusable components, and how to model them in structure diagrams n What is meant by ‘pattern’, and how patterns are used in software development

© Bennett, McRobb and Farmer 2005 References n Bennett, McRobb and Farmer (2005) n Ambler (2003) n Cheesman and Daniels (2001) n Coad (1997) n Fowler (1997) (For full bibliographic details, see Bennett, McRobb and Farmer)