24
Ch4: Software Architecture and Design

Ch4: Software Architecture and Design

  • Upload
    adli

  • View
    37

  • Download
    4

Embed Size (px)

DESCRIPTION

Ch4: Software Architecture and Design. Object-oriented paradigm. Object-oriented decomposition: Agents comprised of two parts: Hidden implementation: Public interface: An Agent can only be modified by operations defined in either the hidden implementation or public interface. - PowerPoint PPT Presentation

Citation preview

Page 1: Ch4: Software Architecture and Design

Ch4: Software Architecture and Design

Page 2: Ch4: Software Architecture and Design

2

Object-oriented paradigm

Object-oriented decomposition:

Agents comprised of two parts: Hidden implementation:

Public interface:

An Agent can only be modified by operations defined in either the hidden implementation or public interface.

Page 3: Ch4: Software Architecture and Design

3

Core object oriented concepts

Class

Information:

Method

Object

Message

Page 4: Ch4: Software Architecture and Design

4

Class

class name

attributes:

operations:

external entities

things

occurrences rolesorganizational units

placesstructures

•A class is a generalized description of a collection of similar objects.•Object is an instance of a class.•Class exports: -Operations used to manipulate instances -May export attributes.

Page 5: Ch4: Software Architecture and Design

5

Two representations of a class

class name

attributes:

operations:

attributes:

operations

Page 6: Ch4: Software Architecture and Design

6

Operations (or methods or services)

•An executable procedure that is a part of a class and operates on the data attributes defined as part of the class.•A method operates on all instances of a class•A method is invoked via message passing.

Page 7: Ch4: Software Architecture and Design

7

Messages

sender object

attributes:

operations:

receiver object

attributes:

operations:

message: [receiver, operation, parameters]

message: [sender, return value(s)]

Messages - the means by which objects invoke each other’s methods.

Page 8: Ch4: Software Architecture and Design

8

An example Employee classClass Employee {

}

//Hidden ImplementationPrivate: //Instance Vars char[30] name; float salary;//Public InterfacePublic: void print_name(); void print_salary(); void update_salary(float i); Employee(char *n, float s);

Main(){//Declare ObjectsEmployee emp1(A,100.0);Employee emp2(B,120.0);

//Pass Messages//Invoke Methodsemp1.print_name();emp1.print_salary();emp2.update_salary(10);emp2.print_name();emp2.print_salary();}

What’s Output of Main()?A100.0B130.0

Conclusion: Each Object (emp1,emp2) has Own Independent State that is Accessible via Shared Public Interface of Class

Page 9: Ch4: Software Architecture and Design

9

Classes vs. ADTs

Classes extend ADTs as follows: Message passing:

Inheritance:

Polymorphism:

ADT/OO benefits:

Page 10: Ch4: Software Architecture and Design

10

How to choose objects and classes

The first and most often raised concern for newcomers to OO concepts

Typical answers:

Better answer:

Page 11: Ch4: Software Architecture and Design

11

How to choose objects and classes (contd..)

Employee class Private data:

Public interface:

Based on an information perspective, focusing on the idea that to track Employees a set of standard data and operations are needed.

Page 12: Ch4: Software Architecture and Design

12

How to choose objects and classes (contd..)

ATM_log class: Private data:

Public interface:

Embodies the functions that take place to authenticate an individual to an ATM session.

Even with a functional view, information is needed to capture user input for verifying status.

Page 13: Ch4: Software Architecture and Design

13

How to choose objects and classes (contd..)

ATM_User:

Private data:

Public interface:

User interface by capturing the different interactions between the ATM and the user.

Page 14: Ch4: Software Architecture and Design

14

How to choose objects and classes (contd..)

An appointments system that will allow telephone callers to book an appointment with a doctor. The caller will specify the day and the time when he wishes to be seen by a doctor.

Tentative classes could be:

Page 15: Ch4: Software Architecture and Design

15

How to choose classes and objects (contd..)

Redundancy:

Discard nouns outside the system domain

Vagueness:

Attributes:

Page 16: Ch4: Software Architecture and Design

16

How to choose classes and objects (contd..)

Operations:

Page 17: Ch4: Software Architecture and Design

17

How to choose objects and classes (contd..)

Attributes are properties of individual objects Can be

Nouns followed by “of the” (E.g. day “of the” appointment) Adjectives - color, number, state (on/off)

May not be fully described Guidelines for identifying attributes:

Attributes that are directly relevant to the problem. Something can be an attribute in one context and an object in another e.g city.

Give them meaningful names. Avoid attributes that are purely involved in implementation e.g an

id number that is generated by the machine and has meaning only within the application.

Avoid attributes that can be derived from existing information e.g. age can be derived from date of birth

Different and unrelated attributes in a class may suggest that the class is a composite of a number of classes. Useful to divide such a class into a number of separate classes.

Page 18: Ch4: Software Architecture and Design

18

How to choose objects and classes (contd..)

Identifying operations:

Attributes:

Events in the scenarios: A scenario consists of interactions (events exchanged) that

have to take place among the objects to achieve the functionality.

Identify common and rare scenarios. Events passed to and from the objects implies operation on

the object or message from it.

Page 19: Ch4: Software Architecture and Design

19

How to choose objects and data (contd..)

Real world can also suggest the operations needed to support a class :

Operations should not overlap each other:

Number of operations that have access to the data should be reduced to a minimum.

Operations may refer to verbs in the problem description

Page 20: Ch4: Software Architecture and Design

20

High-Tech Supermarket System (HTSS)

Automate the functions and actions: Cashiers and inventory updates User friendly grocery item locator Fast-track deli orderer Inventory control

User system interfaces Cash register/UPC scanner GUI for inventory control Shopper interfaces locator and orderer Deli interface for deli workers

Page 21: Ch4: Software Architecture and Design

21

HTSS (contd..)

ICICICIC

CRCRCRCR

CRCR

CRCR

ILILILIL

ILILSDOSDO

SDO EDOEDO

EDOEDO

OrderOrder

PaymentPayment

ItemItemItemDBItemDBLocalLocalServerServer

Non-LocalClient Int.

InventoryInventoryControlControl

ItemDBItemDBGlobalGlobalServerServer

OrderDBOrderDB

SupplierDBSupplierDB

CreditCardDBCreditCardDB

ATM-BanKDBATM-BanKDB

IL: Item LocatorIL: Item LocatorCR: Cash RegisterCR: Cash RegisterIC: Invent. ControlDO: Deli Orderer forDO: Deli Orderer for Shopper/EmployeeShopper/Employee

Page 22: Ch4: Software Architecture and Design

22

Classes in the HTSS

Nouns:

Noun extraction:

Do we need classes for customers/shoppers? Nouns such as aisle, shelf, UPC, etc. do not have any

independent existence, in fact, they represent attributes of item.

Page 23: Ch4: Software Architecture and Design

23

Classes in HTSS

A class based on knowledge of the problem domain: Receipt

There are other kinds of classes, mostly in the solution domain (do not represent any physical entity or a concept in the problem domain), that noun extraction does not reveal. Classes to represent GUIs. Collection classes such as linked lists, queues, stacks

Attributes based on domain knowledge: Retail cost, whole sale cost, etc.

Page 24: Ch4: Software Architecture and Design

24

Item class in HTSS

Item class Attributes:

Operations: