SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture # 16 Finalizing the Application Design SWE 316: Software Design and

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser

Obj

ecti

ves

Lecture # 16Finalizing the Application Design

SWE 316: Software Design and Architecture

Be able to … complete a detailed design

Ch 14bAdapted from Software Design: From Programming to Architecture by Eric J. Braude (Wiley 2003), with permission.


Process Phases Discussed in This ChapterRequirements

Analysis

Design

Implementation

ArchitectureFramework Detailed Design

xKey: = secondary emphasisx = main emphasis

IntroDesigning

ControlDesigning for

InterfacesData Access

Completing the Design

2/24


Relating Use Cases, Architecture, & Detailed Design

1. Use case (part of requirements)

“Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.”

3. Architecure2. Domainclasses

Auto

Road

Auto

Road

4. DetailedDesign

Cable

Cable

Pylon

Pylon

(not specifically required)

added for detailed design

GuardrailRoadbed

*

**

* Use cases used toobtain domain classes. ** Use cases used to verify and test design.

IntroDesigning




3/24


Completing Detailed Design Design the control of the application, Design for database access Design interaction with outside world. Audit relationships among classes

eliminate unnecessary connections, adding requried detail classes clarify all classes

Ensure all required methods implemented

IntroDesigning




4/24


Designing control

Controlling an application: organizing the actions and events that it needs to progress through. Global Control: for the entire application

Internally driven control Externally driven control

Local control: of the parts

14.5.1

Intro Designing Control

Designing for Interfaces

Data AccessCompleting the

Design5/24


Architecture Options for Application Control

Internally driven Externally driven

== “event-driven” Does nothing until an

even occurs e.g., mouse actions Each event causes a

method to execute

event

Application

class

event event

… Globally: Event-driven (externally) or internally.… Locally: May collect control in its own class.

KEY CONCEPTControl Applications

Intro Designing Control


Data AccessCompleting the

Design6/24



Styles of Object-Oriented Design for Application Interface

Internally-driven Interface Design Class by class process

Externally-driven Interface Design by use case -- or -- by screen -- or -- by user

14.5.2

IntroDesigning




7/24


Connecting to Databases

1. Ensure class model supports collection

2. Choose centralized or distributed storage architecture

3. Store data in relational or object-oriented database

14.5.3

IntroDesigning


Interfaces Data AccessCompleting the

Design8/24


Ensure Object Model Allows Data Capture

Mediator for data captureTransaction

Account

Customer Teller

IntroDesigning



Design9/24


Data Management Architectures

Distributed : objects store themselves

Central : use specialized storage classes to create instances

to destroy instances

to make efficient use of space

e.g. garbage collection

IntroDesigning



Design10/24


Transaction float timeCustomer* custCheckAccount* chAccSavingsAccount* svgAcc

store() cassie: Customer“3 Main”: addr

edward: Teller54321: empNum

Objects store themselves

cAcc16: CheckAccount100: lastWithdrawal

sAcc12: SavingsAccount3003: balance

trans129:Transaction

time: 0932

Distributed Data Storage

IntroDesigning



Design11/24


Objects send their contents to a storage utility class or module

attribute values Storage

store(...)

transaction123: Transactiontime: 0932

Object…:Class…

Object…:Class…

Data Storage Package

Centralized Data Storage

IntroDesigning



Design12/24


Transactiontime

customeraccount

DBMSDBMS

Objects re-assembled in memory by application and database.

Data, not objects stored.

tables

Using Relational Databases with OO

DBMS: Database Management SystemDBMS: Database Management System

IntroDesigning



Design13/24


Objects delivered to memory for re-use.

Objects, not data, stored.

Transactiontime

customeraccount

OODBMSOODBMS

tables

OO Databases

IntroDesigning



Design14/24


Customer: cassie

addr: 3 Main

Check Account: cAcc16

lastWithdr: $100

Savings Account: sAcc12

lastWithdr: $300

Teller: edward

empNum: 543210

Transaction: trans129

time: 0932

Customer: cassie

addr: 3 Main

Check Account: cAcc16

lastWithdr: $100

Savings Account: sAcc12

lastWithdr: $300

Teller: edward

empNum: 543210

Transaction: trans129

time: 0932

OO Databases: Relationships Maintained

IntroDesigning



Design15/24


Relational DBMS vs. OO DBMS

RDBMS based on a data model

tables of rows & columns

ODBMS based on a programming technology

(the OO method)

data model defined by the program

IntroDesigning



Design16/24



Replace ambiguous associations,

Expose all dependencies

Split selected classes for improved design.

14.5.4

We reduce dependencies among classes to promote their reuse in other applications.

KEY CONCEPTDesign Goal: Reusability

IntroDesigning


InterfacesData Access Completing the

Design17/24


Examining Associations: Many-To-Many

... may uncover a required class: an "event-remembered" or mediator (Registration in this case).

1..n 1.. n

11 1..n

e.g. wedding gift registration system:

Store Couple

Store Couple1..n

Registration

IntroDesigning



Design18/24


Examining Associations: Class-to-Itself ...

Business

Business JointVenture

... may uncover a required class: frequently an "event-remembered"

Business Merger

2...n

2...n

IntroDesigning



Design19/24


Examining Aggregations for Short Circuits

Item1..n

Shelf1..n

------ But not every item is on a shelf -----

Add:

Supermarket

Item1..n

Shelf1..n

Supermarket

0..nlooseItem

IntroDesigning



Design20/24


Consider Splitting Classes

Envision system growth Leverage inheritance

properly

WinProcedureHelp

Help

WinProcedure

IntroDesigning



Design21/24


Completing Operations

1. Required by…

Class

Operations

1.1 Use-case model (sequence diagrams)

1.2 State Model (event handlers; functionality on entering states)

2. Design the algorithm for each operation (activity diagrams? pseudocode?)

1.4 Design Patterns

1.3 Component model

IntroDesigning



Design22/24


getCategory()

showCategoryOptions()

demoExample()

WinHelpgetProblem()

match()u

u

WinProceduredescribe()u

Partial Component Model

WinProcedureExampledemoExample()c

WinProblemgetCategory()

getVisible()

savePrimaryParameters()showCategoryOptions()

c

u

s

c

key: from... u: use case s: from state model c: from component model

category

String

Completing WinHelp Operations

IntroDesigning



Design23/24


Summary1. Design for data capture 2. Design control 3. Design interfaces4. Exploit abstraction 5. Reduce many-to-many associations6. Finalize design of associations7. Obtain all functions from use case-,

state-, and component models8. Design individual functions

IntroDesigning




24/24

Documents

SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture # 16 Finalizing the Application Design SWE 316: Software Design and