Object Oriented Design II-Software Engineering-Lecture Slides, Slides of Software Engineering

Software Engineering one of core subject in Computer Science. This lecture was delived by Dr. Shrya Gopal at Bengal Engineering and Science University as one of lecture from lecture series on course. This lecture includes: Object-oriented, Design, Implementation, Requirements, Specification, Attributes, Idnetification, Candidate, Relation, Class, Members

Typology: Slides

2011/2012

Uploaded on 08/26/2012

parveen
parveen 🇮🇳

4.6

(9)

88 documents

1 / 25

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CS 501: Software Engineering
Fall 2000
Lecture 12
Object-Oriented Design II
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19

Partial preview of the text

Download Object Oriented Design II-Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!

CS 501: Software Engineering

Fall 2000

Lecture 12

Object-Oriented Design II

docsity.com

Administration

  • Presentations

Your will have three presentations this semester Everybody in the team should present at least once

  • A case study: a new client Client satisfaction is the first requirement!

docsity.com

Requirements, Design and Implementation

Remember the definitions. Example: Consistency between two players of a board game

  • The requirement is .....
  • The design is ..... What is a requirements specification?

docsity.com

Modeling Classes

Given a real-life system, how do you decide what classes to use?

  • What terms do the users and implementers use to describe the system? They are candidates for classes.
  • Is each candidate class crisply defined?
  • For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes?
  • What attributes and operations does each class need to carry out its responsibilities?

docsity.com

Noun Identification: A Library Example

The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals. The system must keep track of when books and journals are borrowed and returned and enforce the rules. docsity.com

Candidate Classes

Library the name of the system Book Journal Copy ShortTermLoan event LibraryMember Week measure MemberOfLibrary repeat Item book or journal Time abstract term MemberOfStaff System general term Rule general term docsity.com

Operations

LibraryMember borrows Copy

LibraryMember returns Copy

MemberOfStaff borrows Journal

MemberOfStaff returns Journal

Item not needed yet.

docsity.com

Class Diagram

MemberOfStaff

Journal Copy is a copy of Book 1..* 1

LibraryMember

0..12^ 0..*

on loan^ on loan

docsity.com

Rough Sketch: Wholesale System

RetailStore

Warehouse

Order

Invoice

Product

Shipment

Merchant

docsity.com

Rough Sketch: Wholesale System

Warehouse Order

Invoice

Product

RetailStore^ Merchant

name address contactInfo financialInfo

Shipment

Responsibilities -track status of shipped products Reversals damaged() return() wrongItem()

responsibility (text field)

docsity.com

Modeling Invoice

Shipment

Invoice invoiceNumber +goodsShipped() -sendInvoice()

goodsShipped PartsList _adornments

  • public_

- private

??? RetailStore invoiceRecord

docsity.com

Lessons Learned

Design is empirical. There is no single correct design. During the design process:

  • Eliding: Elements are hidden to simplify the diagram
  • Incomplete: Elements may be missing.
  • Inconsistency: The model may not be consistent

The diagram is not the whole design. Diagrams must be backed up with specifications.

docsity.com

Component Diagram

HelloWorld.class

hello.java

hello.hml

hello.jpg

executable component

docsity.com

Actor and Use Case Diagram

  • An actor is a user of a system in a particular role. An actor can be human or an external system.
  • A use case is a a task that an actor needs to perform with the help of the system.

Borrow book

BookBorrower

docsity.com