03/12/2001 © Bennett, McRobb and Farmer 2002 1 Transition to Design Based on Chapter 12 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.

Slides:



Advertisements
Similar presentations
COMP1007 Introduction to Requirements Analysis © Copyright De Montfort University 2002 All Rights Reserved COMP1007 Introduction to Requirements Analysis.
Advertisements

Chapter 12 Review Questions
Ch 3: Unified Process CSCI 4320: Software Engineering.
Software Process Models
10 Software Engineering Foundations of Computer Science ã Cengage Learning.
1 Information Systems Development (ISD) Systems Development Life Cycle Overview of Analysis Phase Overview of Design Phase CP2236: Information Systems.
Ch 3 System Development Environment
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
Moving from Analysis to Design. Overview ● What is the difference between analysis and design? ● Logical v. physical design ● System v. detailed design.
Computer Engineering 203 R Smith Requirements Management 6/ Requirements IEEE Standard Glossary A condition or capability needed by a user to solve.
03/12/2001 © Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis.
Software Engineering For Beginners. General Information Lecturer, Patricia O’Byrne, office K115A. –
03/12/2001 © Bennett, McRobb and Farmer Activity Diagrams Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
© Bennett, McRobb and Farmer 2005
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
03/12/2001 © Bennett, McRobb and Farmer Development Process Based on Chapter 5 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Objectives Explain the purpose and objectives of object- oriented design Develop design class diagrams Develop interaction diagrams based on the principles.
Chapter 9: Moving to Design
03/12/2001 © Bennett, McRobb and Farmer Use Case Diagrams Based on Chapter 6 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
1 A Student Guide to Object- Orientated Development Chapter 9 Design.
Spring 2009CS 225 Introduction to Software Design Chapter 1.
Systems Design. Analysis involves understanding and documenting user requirements in a clear and unambiguous way. It focuses on the business side and.
Problem with Software Requirements are complex The client does not know the functional requirements in advance Requirements may be changing Technology.
Chapter 1 Introduction to Databases
Continuation From Chapter From Chapter 1
The Design Discipline.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
1 Shawlands Academy Higher Computing Software Development Unit.
Chapter 1 The Systems Development Environment
1 BTEC HNC Systems Support Castle College 2007/8 Systems Analysis Lecture 9 Introduction to Design.
Chapter 1: The Object-Oriented Systems Development Environment Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
An Introduction to Software Architecture
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
4/2/03I-1 © 2001 T. Horton CS 494 Object-Oriented Analysis & Design Software Architecture and Design Readings: Ambler, Chap. 7 (Sections to start.
1 The Software Development Process  Systems analysis  Systems design  Implementation  Testing  Documentation  Evaluation  Maintenance.
Systems Design Approaches The Waterfall vs. Iterative Methodologies.
Asst.Prof. Dr. Surasak Mungsing. 3 Learning Objectives Explain the purpose and various phases of the systems development life cycle (SDLC) Explain when.
Project Life Cycles.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Architectural Design l Establishing the overall structure of a software system.
Systems Analysis and Design in a Changing World, 3rd Edition
I Power Higher Computing Software Development The Software Development Process.
THE DESIGN WORKFLOW  Object-oriented design  The design workflow  The test workflow: Design  CASE tools for design  Challenges of the design workflow.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
© 2010 Bennett, McRobb and Farmer1 Development Process Based on Chapter 5 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using.
INFO1408 Database Design Concepts Week 15: Introduction to Database Management Systems.
© 2010 Bennett, McRobb and Farmer1 Moving into Design Based on Chapter 12 Bennett, McRobb and Farmer Object Oriented Systems Analysis and Design Using.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
The Software Development Process
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Topic 4 - Database Design Unit 1 – Database Analysis and Design Advanced Higher Information Systems St Kentigern’s Academy.
© Bennett, McRobb and Farmer 2005
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) CSE323 การวิเคราะห์และออกแบบระบบ (Systems Analysis and Design) Lecture.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Design and Development Development Methodoligies Computing Science.
Why is Design so Difficult? Analysis: Focuses on the application domain Design: Focuses on the solution domain –The solution domain is changing very rapidly.
Development Process Based on Chapter 5 Bennett, McRobb and Farmer
Chapter 1: Introduction to Systems Analysis and Design
CIS511 Information System Architecture
An Introduction to Software Architecture
CS310 Software Engineering Lecturer Dr.Doaa Sami
Systems Analysis and Design I
Software Architecture
Chapter 6: Architectural Design
Chapter 1: Introduction to Systems Analysis and Design
Presentation transcript:

03/12/2001 © Bennett, McRobb and Farmer Transition to Design Based on Chapter 12 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design Using UML, (2 nd Edition), McGraw Hill, 2002.

© Bennett, McRobb and Farmer In This Lecture You Will Learn: n The difference between analysis and design n The difference between logical and physical design n The difference between system and detailed design n The characteristics of a good design n The need to make trade-offs in design

© Bennett, McRobb and Farmer How is Design Different from Analysis? n Design states ‘how the system will be constructed without actually building it’ (Rumbaugh, 1997) n Analysis identifies ‘what’ the system must do n Design specifies ‘how’ it will do it

© Bennett, McRobb and Farmer How is Design Different from Analysis? n The analyst seeks to understand the organization, its requirements and its objectives n The designer seeks to specify a system that will fit the organization, provide its requirements effectively and assist it to meet its objectives

© Bennett, McRobb and Farmer How is Design Different from Analysis? n As an example, in the Agate case study: –analysis identifies the fact that the Campaign class has a title attribute –design determines how this will be entered into the system, displayed on screen and stored in a database, together with all the other attributes of Campaign and other classes

© Bennett, McRobb and Farmer When Does Analysis Stop and Design Start? n In a waterfall life cycle there is a clear transition between the two activities n In an iterative life cycle the analysis of a particular part of the system will precede its design, but analysis and design may be happening in parallel n It is important to distinguish the two activities and the associated mindset n We need to know ‘what’ before we decide ‘how’

© Bennett, McRobb and Farmer Traditional Design n Making a clear transition from analysis to design has advantages –project management—is there the right balance of activities? –staff skills—analysis and design may be carried out by different staff –client decisions—the client may want a specification of the ‘what’ before approving spending on design –choice of development environment—may be delayed until the analysis is complete

© Bennett, McRobb and Farmer Design in the Iterative Life Cycle n Advantages of the iterative life cycle include –risk mitigation—making it possible to identify risks earlier and to take action –change management—changes to requirements are expected and properly managed –team learning—all the team can be involved from the start of the project –improved quality—testing begins early and is not done as a ‘big bang’ with no time

© Bennett, McRobb and Farmer Seamlessness n The same model—the class model—is used through the life of the project n During design, additional detail is added to the analysis classes, and extra classes are added to provide the supporting functionality for the user interface and data management n Other diagrams are also elaborated in design activities

© Bennett, McRobb and Farmer Logical and Physical Design n In structured analysis and design a distinction has been made between logical and physical design n Logical design is independent of the implementation language and platform n Physical design is based on the actual implementation platform and the language that will be used

© Bennett, McRobb and Farmer Logical and Physical Design Example n Some design of the user interface classes can be done without knowing whether it is to be implemented in Java, C++ or some other language—types of fields, position in windows n Some design can only be done when the language has been decided upon—the actual classes for the types of fields, the layout managers available to handle window layout

© Bennett, McRobb and Farmer Logical and Physical Design n It is not necessary to separate these into two separate activities n It may be useful if the software is to be implemented on different platforms n Then it will be an advantage to have a platform-independent design that can be tailored to each platform

© Bennett, McRobb and Farmer System Design and Detailed Design n System design deals with the high level architecture of the system –structure of sub-systems –distribution of sub-systems on processors –communication between sub-systems –standards for screens, reports, help etc. –job design for the people who will use the system

© Bennett, McRobb and Farmer System Design and Detailed Design n Traditional detailed design consists of four main activities –designing inputs –designing outputs –designing processes –designing files and database structures

© Bennett, McRobb and Farmer System Design and Detailed Design n Traditional detailed design tried to maximise cohesion –elements of module of code all contribute to the achievement of a single function n Traditional detailed design tried to minimise coupling –unnecessary linkages between modules that made them difficult to maintain or use in isolation from other modules

© Bennett, McRobb and Farmer System Design and Detailed Design n Object-oriented detailed design adds detail to the analysis model –types of attributes –operation signatures –assigning responsibilities as operations –additional classes to handle user interface –additional classes to handle data management –design of reusable components –assigning classes to packages

© Bennett, McRobb and Farmer Elaborating Classes in Packages Presentation Layer Package Application Logic Layer Package JDBC Java SQL Java AWT Application Windows Storage Layer Package Business Objects Control Objects Object to Relational

© Bennett, McRobb and Farmer Assigning Responsibilities Invoice InvoiceLineProduct TaxRate 1..* 1 1 * appears on 1 * applies to

© Bennett, McRobb and Farmer Qualities of Analysis n Correct scope—everything in the system is required n Completeness—everything required is in the system and everything is documented in the models n Correct content—accurate description of requirements n Consistency—each element is consistently referred to by the same name

© Bennett, McRobb and Farmer Qualities of Design n Functional—system will perform the functions that it is required to n Efficient—the system performs those functions efficiently in terms of time and resources n Economical—running costs of system will not be unnecessarily high n Reliable—not prone to hardware or software failure, will deliver the functionality when the users want it

© Bennett, McRobb and Farmer Qualities of Design n Secure—protected against errors, attacks and loss of valuable data n Flexible—capable of being adapted to new uses, to run in different countries or to be moved to a different platform n General—general-purpose and portable (mainly applies to utility programs) n Buildable—Design is not too complex for the developers to be able to implement it

© Bennett, McRobb and Farmer Qualities of Design n Manageable—easy to estimate work involved and to check of progress n Maintainable—design makes it possible for the maintenance programmer to understand the designer’s intention n Usable—provides users with a satisfying experience (not a source of dissatisfaction) n Reusable—elements of the system can be reused in other systems

© Bennett, McRobb and Farmer Trade-offs in Design n Design to meet all these qualities may produce conflicts n Trade-offs have to be applied to resolve these n Functionality, reliability and security are likely to conflict with economy n Level of reliability, for example, is constrained by the budget available for the development of the system

© Bennett, McRobb and Farmer Trade-offs in Design n Design objectives may conflict with constraints imposed by requirements n The requirement that the system can be used in different countries by speakers of different languages will mean that designers have to agree a list of all prompts, labels and messages and refer to these by some system of naming or numbering n This increases flexibility and maintainability but increases the cost of design

© Bennett, McRobb and Farmer Measurable Objectives in Design n In Chapter 6, non-functional requirements were described n How can we tell whether these have been achieved? n Measurable objectives set clear targets for designers n Objectives should be quantified so that they can be tested

© Bennett, McRobb and Farmer Measurable Objectives in Design n To reduce invoice errors by one-third within a year n How would you design for this?

© Bennett, McRobb and Farmer Measurable Objectives in Design n To reduce invoice errors by one-third within a year n How would you design for this? –sense checks on quantities –comparing invoices with previous ones for the same customer –better feedback to the user about the items ordered

© Bennett, McRobb and Farmer Measurable Objectives in Design n To process 50% more orders at peak periods n How would you design for this?

© Bennett, McRobb and Farmer Measurable Objectives in Design n To process 50% more orders at peak periods n How would you design for this? –design for as many fields as possible to be filled with defaults –design for rapid response from database –design system to handle larger number of simultaneous users

© Bennett, McRobb and Farmer Planning for Design n Planning for when platform is known n Setting standards n Allowing time for training n Agreeing objectives and planning tests n Agree procedures to decide on trade- offs that significantly affect the system n Planning time for different aspects of design

© Bennett, McRobb and Farmer Summary In this lecture you have learned about: n The difference between analysis and design n The difference between logical and physical design n The difference between system and detailed design n The characteristics of a good design n The need to make trade-offs in design

© Bennett, McRobb and Farmer References n More detail about design is provided in Chapters 13 to 18 n In particular, Chapter 13 covers System Design and Chapter 14 covers Class Design (For full bibliographic details, see Bennett, McRobb and Farmer)