Object-oriented Design CSCI 5801: Software Engineering.

Slides:



Advertisements
Similar presentations
Design Validation CSCI 5801: Software Engineering.
Advertisements

Use Case & Use Case Diagram
1 Object-oriented design Part 2: OO tools & UML. 2 CRC cards Design tool & method for discovering classes, responsibilities, & relationships Record on.
1 Software Engineering Lecture 11 Software Testing.
Use Case Modeling SJTU. Unified Modeling Language (UML) l Standardized notation for object-oriented development l Needs to be used with an analysis and.
System Modelling System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Different.
CS 106 Introduction to Computer Science I 04 / 11 / 2008 Instructor: Michael Eckmann.
Ch 12: Object-Oriented Analysis
Requirements and Design
Information System Design IT60105
Chapter 12 ATM Case Study, Part 1: Object-Oriented Design with the UML
ATM User Interface Design. Requirements A bank customer is able to access his or her account using an automatic teller machine. To be able to use an ATM.
Object-Oriented Analysis and Design
Introduction To System Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Java Programming, 3e Concepts and Techniques Chapter 5 Arrays, Loops, and Layout Managers Using External Classes.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
Lecture 4 Class Responsibility Collaboration Cards
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Object Oriented Analysis Process
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 8 Slide 1 System models.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
Chapter 13: Object-Oriented Programming
Marcelo Santos – OOAD-CDT309, Spring 2008, IDE-MdH 1 Object-Oriented Analysis and Design - CDT309 Period 4, Spring 2008 More on use cases System sequence.
©TheMcGraw-Hill Companies, Inc. Permission required for reproduction or display. Chapter 1 Introduction to Object-Oriented Programming and Software Development.
Teamwork Know each other Compete Leadership Strengths and Weaknesses
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 7 Slide 1 System models l Abstract descriptions of systems whose requirements are being.
Software Engineering 8. System Models.
Introduction To System Analysis and design
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
 2003 Prentice Hall, Inc. All rights reserved. 1 Introduction to Classes and Objects Outline Introduction Classes, Objects, Member Functions and Data.
From Problem Statement to Design
CSM-Java Programming-I Spring,2005 Objects and Classes Overview Lesson - 1.
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.
An Introduction to Java Chapter 11 Object-Oriented Application Development: Part I.
Software Life Cycle Requirements and problem analysis. –What exactly is this system supposed to do? Design –How will the system solve the problem? Coding.
1 Object-Oriented Analysis Use Case Driven. 2 The outline method for OOA 1.Identify object classes within the problem domain 2.Define the behaviour of.
Faculty of Computer & Information Software Engineering Third year
Requirements Documentation CSCI 5801: Software Engineering.
Java Programming: Guided Learning with Early Objects
Chapter 7 System models.
Slide 1 System models. Slide 2 Objectives l To explain why the context of a system should be modelled as part of the RE process l To describe behavioural.
System models l Abstract descriptions of systems whose requirements are being analysed.
Pertemuan 19 PEMODELAN SISTEM Matakuliah: D0174/ Pemodelan Sistem dan Simulasi Tahun: Tahun 2009.
Modified by Juan M. Gomez Software Engineering, 6th edition. Chapter 7 Slide 1 Chapter 7 System Models.
Modeling Shari L. Pfleeger and Joanne M. Atlee, Software Engineering: Theory and Practice, 4 th edition, Prentice Hall, Hans Van Vliet, Software.
Software Engineering, 8th edition Chapter 8 1 Courtesy: ©Ian Somerville 2006 April 06 th, 2009 Lecture # 13 System models.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Fall 2010 CS4310 Requirements Engineering A Brief Review of UML & OO Dr. Guoqiang Hu Department of Computer Science UTEP 1.
BCS 2143 Object Oriented Design Using UML. Objectives Objects Interactions Finding Classes Relationship Between Classes Attribute and Operation Class.
CS 772: Global Knowledge Networks V. “Juggy” Jagannathan CSEE, West Virginia University.
CS 151: Object-Oriented Design September 5 Class Meeting Department of Computer Science San Jose State University Spring 2013 Instructor: Ron Mak
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
Class Builder Tutorial Presented By- Amit Singh & Sylendra Prasad.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
ITEC324 Principle of CS III Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Chapters 10, 11 SSD (Revision) SD DCD Exam Object-Oriented Design.
Identification of Classes. Object Oriented Analysis (OOA) OOA is process by which we identify classes that play role in achieving system goals & requirements.
Chapter 2 (Horstmann’s Book) – Part 1 The Object-Oriented Design Process Hwajung Lee.
Inf 43: Introduction to Software Engineering May 7, 2016.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
Java Programming: Guided Learning with Early Objects Chapter 9 Inheritance and Polymorphism.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
CMPE 280 Web UI Design and Development August 29 Class Meeting
ATM OO Design and Implementation Case Study
About the Presentations
OO Domain Modeling With UML Class Diagrams and CRC Cards
Presentation transcript:

Object-oriented Design CSCI 5801: Software Engineering

Object-oriened Design

Program Design Given a system architecture, the program design specifies: – Components, packages, classes and class hierarchies – Interfaces and protocols between them – The basic algorithms, data structures, security mechanisms, operational procedures, etc. that each will use If the program design is done properly, implementation can proceed directly from it

Design Documentation Diagrams: – Basic information about packages and classes (name, data contained, basic role) – Relationships to other packages/classes Specifications: – Application Programming Interface: Detailed list of functions/method prototypes – Basic algorithm/UI design to meet non-functional requirements

Object-oriented Programming Object = Data + Code to manipulate that data – Data-driven decomposition – Well-defined interfaces in terms of methods Objects are instances of a class which defines – Data type (member variables) stored in object – Methods to allow user to manipulate that data – Constructors that define how objects initialized – Can implement interfaces (validated by compiler) Package is set of related classes (like a library)

Object-oriented Programming OOP commonly used for large-scale programming – Don’t have to know how other components implemented – Just need to know how to use methods at interface “Client programmer”: Programmer who uses class in their own code Methods to manipulate state of object Current state of object Object Only has to understand how to call methods, not how they work Do not have to understand internal representation of object state

UML for Classes Abstract description of class Data stored in objects of this class Prototypes of methods this class implement at interface Abstract description of what class does in terms of the goal of the system

UML for Classes Example: Roster class (in Registration package)

Relational UML for Classes Used to show relationships between classes – Composition One class contains an instance of another as a member variable – Association Objects that communicate with one another – Generalization One class extends another via inheritance – Implements Implements interface used by other component

Composition Relationship One class composed of others as member variables Can give number of entities aggregate type contains – Can be range (1..4) – *  any number from 0 to ∞ +  any number from 1 to ∞

Association Relationship Objects communicate via some defined relationship (other than composition) Can show complex data types passed for communication

Generalization Relationship Subclasses extend a superclass – Inherit all member variables, methods – Can add variables, add/override methods – Superclass can be abstract Only exists to be extended to actual subclasses

Interface Relationship Class calls methods specified in interface another class implements

UML Example

Design Documentation No standard form for design documentation However, it often contains at global level: – Overall architecture (in UML) – Sequence diagrams for major processes showing flow between major components – Data dictionary for major components of system – User interface descriptions, database layouts… At package level: – APIs for major classes Non-functional constraints on package Traceability to requirements

Design Documentation No standard form for design documentation However, it often contains at global level: – Overall architecture (in UML) – Sequence diagrams for major processes showing flow between major components – Data dictionary for major components of system At package level: – APIs for major classes Non-functional constraints on package Traceability to requirements

Sample Sequence Diagram

Example Data Dictionary (ATM) Major System Components Account: Data control object storing information about current user LoginInterface: User interface object for ID and PIN entry LoginLogic: Business logic object to check ID and PIN correctness PinDatabase: Data interface object to interact with PIN database PinInterface: User interface to allow administrators to reset PINs WithdrawInterface: User interface object to allow withdrawals WithdrawLogic: Business logic object to validate withdrawals AccountDatabase: Data interface object to account database Actors User: Person logged into system to make withdrawals Administrator: Bank employee authorized to reset PINs PIN Database: Database of account IDs and corresponding PINs Account Database: Database of account information

UI Description (ATM Withdrawal) Description: Provides controls to allow a user to choose an account type to withdraw from, and an amount to withdraw. It displays messages in case of errors. Usability: The interface must prevent illegal choices where possible. This is accomplished by only showing existing accounts and limiting inputs to digits. Visual Appearance and Controls: Account Selector – Type: Drop-down list – Use: Allows user to select account to withdraw from (currently either checking, savings, or credit card). – Initial state: “Please select” – Constraints: Account types not held by user will be disabled

UI Description (ATM Withdrawal) Amount Entry – Type: Text box – Use: allows user to enter withdrawal amount – Initial state: Empty – Constraints: Only accepts digits Withdrawal Button – Type: Button – Use: Pressed by user to perform withdrawal – Event handling: Validates the user has chosen an account type and input a numeric value Calls methods in WithdrawalLogic to perform withdrawal Displays pop-up messages if information entered invalid. Exit Button – Type: Button – Use: Pressed by user to exit process – Event handling: Destroys this object and constructs a new LoginInterface object.

Database Descriptor Example (ATM) Account Database Structure Field NameField TypeDescription AccountNumber Text (15 characters)Primary key, shared with other tables HasSavings Yes/NoDoes this customer have a savings account? SavingsBalance Number (must be positive) Amount in savings account HasChecking Yes/NoDoes this customer have a checking account? CheckingBalance Number (must be positive) Amount in checking account HasCredit Yes/NoDoes this customer have a credit account? CreditBalance Number (must not be negative) Current credit balance CreditLimit Number (must be positive) Credit limit CreditWithdrawalLimit Number (must be positive) Maximum credit withdrawal amount

Application Program Interface Prototypes of class methods – Parameters and return types – Any exceptions thrown – Abstract description of method Abstract description of class – Purpose in context of system – Types of information stored – Examples of use… Everything another programmer needs to know to use the class

API Example A Roster stores all students in a section of a course. Users have the ability to add and remove students, and to get a list of all student objects stored in the Roster. Users may not add the same Student object multiple times, or exceed the maximum size of the Roster (set in the constructor). Internally, students are sorted by ID to allow faster search. This class is traceable to the Add Course and the View Students scenarios Constructor public Roster (int maxSize) Methods public void AddStudent(Student s) public void deleteStudent(String id) public Student[] getRoster() public booolean isOpen() public String serialize() public void deserialize(String s)

API Example public void addStudent(Student s) This method adds the Student object to the roster. It throws a AlreadyInException if the student is already in the roster, or a SectionClosed exception if the number of students is equal to the size set in the constructor (users should check this with isOpen() first). public void deleteStudent(String id) This method removes the student with the given id from the roster. A NoSuchStudent exception is thrown if a student with that id cannot be found.

Object-oriented Design Identify the objects – What are the major nouns used in the description of the system and its scenarios? Determine their attributes and services – What verbs are associated with those nouns? Determine the relationships between objects – What other nouns are mentioned in the same or related sentences?

Example Problem Design the software to support the operation of a public library. The system has a number of stations for customer transactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar code reader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read. SE, Design, Hans van Vliet, ©200826

Candidate objects software library system station customer transaction 27 book library employee identification card client bar code reader book’s code

Carefully consider candidate list Eliminate implementation constructs, such as “software” Replace or eliminate vague terms: “system”  “computer” Equate synonymous terms: “customer” and “client”  “client” Eliminate operation names, if possible (such as “transaction”) Be careful in what you really mean: can a client be a library employee? Is it “book copy” rather than “book”? Eliminate individual objects (as opposed to classes). “book’s code”  attribute of “book copy” 28

Relationships From the problem statement: – employee operates station – station has bar code reader – bar code reader reads book copy – bar code reader reads identification card Tacit knowledge: – library owns computer – library owns stations – computer communicates with station – library employs employee – client is member of library – client has identification card 29

Initial Class Diagram 30

Initial Sequence Diagram 31