Revision:Lecture 1 - 7

1

TMC2413Object Oriented Software

Development

Topics

2

Introduction

• Object-Oriented (OO) systems development is a way to develop software by building self-contained modules that can be more easily:– Replaced– Modified– and Reused.

3

Object-Oriented Systems Development Methodology

• In an O-O environment, software is a collection of discrete objects.

• These objects encapsulate their data and functionalities to model real world "objects."

data

functionalities

4

Benefits of Object Orientation

• Faster development, • Reusability, • Increased quality, • Easier maintenance.

5

Examples

• Example class Car is known as Car in Analysis model, also in Design model, and Implementation model (e.g., car.java)

6

Concepts of object-orientation

i. Classes and objectsii. Attributesiii. Operations, methods and servicesiv. Messagesv. Relationships : Inheritance, Association & Aggregation

vi. Encapsulation, and polymorphism.

7

OO in C++

• Class in C++• Member Functions• Constructor and Destructors • Access Control Rules • Friend Function• Inheritance in C++• Polymorphism in C++

8

Unified modeling language

– Class diagram. – Use case diagram.– Interaction diagrams.

• Sequence diagram. • Collaboration diagram.

– Statechart diagram.– Activity diagram.– Implementation diagrams.

• Component diagram. • Deployment diagram.

9

Use Case Diagram

10

11

Include / Exclude Relationship ???

12

13

14

15

Sequence Diagrams

• sequence diagram: an "interaction diagram" that models a single scenario executing in the system

• relation of UML diagrams to other exercises:– CRC cards class diagram– use cases sequence diagrams

16

Key parts of a sequence diag.

• participant: an object or entity that acts in the sequence diagram– sequence diagram starts with an unattached "found message"

arrow

• message: communication between participant objects

• the axes in a sequence diagram:– horizontal: which object/participant is acting– vertical: time (down -> forward in time)

17 Borrow Books use case

18

Sequence diagram from use case

State Chart Diagram

describe the lifecycle of a given object of a class. 

show all the possible states that the object can get into and the transitions which show how the object's state changes as a result of events that reach the object. 

useful to describe the behaviour of an object across several use cases.

19

Scenario to generate State Chart

Librarians categorise the library books into loanable and non-loanable books. The non-loanable books are the reference books. However, the loanable books are the non-reference books. After cataloguing the books, the books are available for loan. Students who borrow the library books should return them back before the due date. Books that are 12 months over the due date would be considered as a lost state. However, if those books are found in the future, they must be returned back to the library. When the books are found not required in the library or have been damaged, the book would be disposed. 20

21

State Chart diagram of an object of class Book

Other example of State Chart

22

Classification: Approaches for Identifying Classes

The noun phrase approach. The common class patterns approach. The use-case driven approach. The class responsibilities collaboration (CRC)

approach.

23

24

Software Lifecycle phases

• software lifecycle: series of steps / phases– Requirements Analysis & Specification– High-level (Architectural) Design– Detailed (Object-oriented) Design– Implementation, Integration, Debugging– Testing, Profiling, Quality Assurance– Operation and Maintenance– other possibilities: Risk Assessment, Prototyping

in each phase:– mark out a clear set of steps to perform– produce a tangible document or item– allow for review of work– specify actions to perform in the next phase

Life Cycle Modeling

–Waterfall model–V-model–Spiral model–Unified approach/Unified Process (UP)

• Inception phase • Elaboration phase • Construction phase• Transition phase

25

26

Waterfallrequirements

verify

retirement

operations

testimplementverify

design

req. change

assumes requirements will be clear and well-understood requires a lot of planning up front (not always easy) rigid, linear; not adaptable to change in the product costly to "swim upstream" back to a previous phase nothing to show until almost done ("we're 90% done I swear!")

benefits formal, standard; specific phases with clear goals good feedback loops between adjacent phases

drawbacks?

27

steps taken at each loop: determine objectives, constraints identify risks evaluate options to resolve the risks develop and verify any deliverable items

benefits provides early indication of unforeseen problems always addresses the biggest risk first accommodates changes, growth eliminates errors and unattractive choices early

drawbacks?

SpiralBarry Boehm, USC

relies on developers to have risk-assessment expertise complex; works poorly when bound to an inflexible contract

28

Evolutionary

build initial requirements, code it, "evolve" as needed produces steady signs of progress, builds customer confidence useful when requirements are not well known or change rapidly customer involvement ("What do you think of this version?")

drawbacks? assumes user's initial spec will be flexible fails for separate pieces that must then be integrated temporary fixes become permanent constraints bridging; new software trying to gradually replace old unclear how many iterations will be needed to finish

for each build:detailed design,implement,test, deliver

requirements

verifyretirement

operations

verify

arch. design

Analysis Design Prototyping and Testing

Ret ur nBoo k?

YesG o t o count erand r et ur n t he

book

Bor r owBooks?

Don e? Yes

Yes

No

Per f or mRes ear ch?

I nt erLibr ayLoa n?

Yes

I nt er Libr ar yLoan Sect io n,

che ck outbook

No Sear ch f or t hebook in t he

libr ar y

Checkingout Books?

G o t o count erand check out

t he bo ok

YesDo Resear c hon t he t opic

No

Rea dnewspa per

/ boo ksYes

Sitsom ewher e

quiet and r eadnewspaper ,book s, et c .

No

Membercomes in

Business process modelingusing activity diagram

Checking AccountBank Client ATM M achine Account

Wit hdr aw Checking Account

Wit hdr aw Successf ul

Request Kind

Ent er Kind

Request Am ount

Ent er Am ount

Pr ocess Tr ansact ion

Tr ansact ion succeed

Dispense Cash

Request Take Cash

Take Cash

Request Cont inuat ion

Term inat e

Pr int Receipt

The advantage of developinga business process model isthat it familiarizes you withthe system and therefore theuser requirements

Use case diagramsUse cases capture the goal of theusers and the responsibility of thesystem to its users

Sequence diagramcollaboration diagram

The process of creating sequence or collaboration diagrams is asystematic way to think about how a use case can take place, and bydoing so, it forces you to think about objects involves in yourapplication

1. Identify the users/actors (Chapter 6): Who is (or will be) using the system?

2. Develop a simple businessprocess model

3. Develop the use case (Chapter 6): What are (or will be) the users aredoing with the system? Use cases provide comprehensivedocumentation of the system understudy

4. Interaction diagrams(Chapter 7) 4.1 Develop sequencediagrams 4.2 Developcollaboration diagrams. 4.3 Iterate and refine

5. Classification (Chapter 8) 5.1 Identify Classes 5.2 Identify Relationships 5.3 Identify Attributes 5.4 Identify Methods 5.5 Iterate and refine.

*

1

1

1

1

1..*

Class diagram

6. Apply design axioms to design classes,their attributes, methods, associations,structures, and protocols (Chapter 9)

6.1. Refine and complete the staticUML class diagram (object model)by adding details to the UML classdiagram (Chapter 10)

6.1.1 Refine attributes6.1.2 Design methods andprotocols by utilizing UMLactivity diagram forrepresentation of method’salgorithm6.1.3 Refine (if required)associations between classes6.1.4 Refine (if required) classhierarchy and design withinheritance

Via Net Ba nk ATM S y tem

Ac co unt

Transact ion

#t r ansDate : Date#t r ansTime : Time#t ransType : St ring#amount : f loat

#postBalance : f loat

Account

#number: St ring#balance : f loat

CheckingAccount

#savings : Account

SavingsAccount

#checking : Account

*

1

Account -Transact ion

1

1

Savings-Checking

1. .*

#t r ansact ion: Transact ion#account : Account

+veri fyPassword()

+deposit ( )

+wi thdraw()

#retri eveAccount( )

+wi thdraw()

#createTransact i on()

#updateAccount()

BankClient

#f ir stName : St ring#lastName :St r ing

#pinNumber : St ring#account : Account

ATMMachine

#cardNumber : St r ing

#address : St r ing

#state : St ring

#bankClient : BankClient

#t ransID : St ring

Refine UML Classdiagram

Che ck ingAc cou nt::+ withdra w (anAm oun t:F loat):Return Code :String

insufficient fund s

Wi thdraw usi ngAccount cl ass

methodAc c ou nt. wit hd ra w ( a n Am o un t)

su fficien t fun ds

Does n' t hav e sa vings

account

wi t hdraw usi ngSavi ngsAccount

method

Savi ngsAccount. wit hdrawSavi ngsAccount. balance -

(anAmount -CheckAccount. bal ance) )

ins uffi cient fu nds

aco unt has sav ing sac cou nt

returnCode="I nsuffi cient

funds"

sufficien t fun ds

returnCode ="O K"

Design methods byutilizing UML Activity

Diagram6.2 Iterate and refine (reapply Designaxioms).

7.0 Design the access ayer (Chapter 11)7.1. Create maccess layer classes by

mirroring the business classes7.2. Define relationships7.3. Simplify classes and structures

7.3.1 Eliminate redundant classes7.3.2 Eliminate method classes

7.4 Iterate and refine

8. Designing view layer classes (Chapter 12)8.1 Macro-level UI design Process- Identifying View layer Objects8.2 Micro-level UI design activities:

8.2.1 Designing the view layer objects by applying designaxioms and corollaries8.2.2 Prototyping the view layer interface.

8.3. Usability and user satisfaction testing (Chapter 14):8.4 Iterate and refine

Tra n s a ct i on

# t ra ns Da te : Da te# t ra n s Time : T ime# tra ns Ty p e : Stri ng

# a mo u n t : f lo a t#p o s tBa la n c e : f l oa t

Ba nk Cl ie n t

#f i rs tNa me : S tri n g# la s tNa me : St rin g

# p in Nu mb e r : St rin g# a c c o u n t : Ac c o u n t

Ac co un t

# n u mb e r: St rin g# b a la n c e : f l o a t

Ch e c k i ng Ac c o u nt

# s av in gs : Ac co u n t

ATMMac hi ne

Sa v in g s Acc ou n t

# c h ec k in g : Ac c o u n t

Ba n K

*

1

Ac c oun t-Tra ns ac ti on

1

1

Sa vi ng s-Ch ec k i ng

1

1. .*

Has

# c a rd Nu mb e r : Strin g

# t ra ns ac ti o n : Tra n s a c ti o n

#a cc o u n t : Ac c o u n t

# a d dre s s : St ri n g# s ta te : St ri n g

+ v eri fy Pa s s wo rd ()

+ d e po si t()

+with d ra w()

-re trie v e Acc o un t()+with draw()

# c re ateT ra n s ac tio n ()

-u pd ate Acc ou ntt( )

# b a nk Cl i e n t: Ba n k Cl ie n t

# tra n s ID : St rin g

Ba nk DB

+ retrie ve Cli en t( )+u pd a te Clie nt()

+re tri e v eSav in g s Ac co u nt()

+u pd a teSav in gs Ac co u nt()

Acc ess Class (es )

Busi ness Cl asses

#b a n k DB: Ban k DB

# b a n k DB: Ba n k DB

+re tri ev eCh e c kin gAcc o un t()+ u pd ateCh e ck in gAcc o u nt()

-re triev eAc c o un t()

-u pd ateAc c ou ntt()

# re tri ev eA cc o un t()

# u p da teAc c o un tt()

UML Class diagramwith added accessand view classes

9. Iterate and refine the design/analysis: If needed repeat the precedingsteps

Create UserInterfacecontrols

Associate actionsto the User

Interface controlsand their events

Test/D ebug

Enter title here

OKCancel

Create the forms and controls

Enter title here

OKCancel

Add Actions

Enter title here

OKCancel

Test the UIDone

Prototype user interface

10 9 8 7 6 5 4 3 2 1Ver y easy t o use Very Har d t o use

Is ea sy to o pe ra te:

How do y ou rate the ViaNet Bank ATM Kios k Interfac e?

10 9 8 7 6 5 4 3 2 1Very appropri at e Not appropri at e

Bu tto ns a re rig ht si z e a nd e as ily c an be l oc ate d:

10 9 8 7 6 5 4 3 2 1Very eff i ci ent Very i nef f i ci ent

Is effic ien t to us e:

10 9 8 7 6 5 4 3 2 1Very Not Fun at al l

Is Fu n to us e:

10 9 8 7 6 5 4 3 2 1Ver y pl easi ng Not pl easi ng

Is v is u all y p le as in g :

Co m m en ts :

I have more t o say, I would like t o see you.

10 9 8 7 6 5 4 3 2 1Ver y easyrecovery Not at al l

Pro vi de s ea sy re co ve ry from errors :

Usability and usersatisfaction testing

OOAD Phases

Quiz

30

Question 1

1. Name ONE iterative software process model.

• Agile Process• RAD• Unified Process

Question 2

2. __________ to extend which software module can be used in different applications.

• Reusability

Question 3

3. _________ is identified with the degree to which system, component or process satisfies specified requirements.

• Quality

Question 4

4. Name TWO quality factors.• Correctness• Reliability• Maintainability• Testability• Efficiency• Usability• Integrity• Portability• Interoperability• Reusability

Question 5

5. The _____ is a variation of waterfall model that makes explicit dependency between development activities and verification activities.

• V-Model