lecture # 16 finalizing the application design

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

Obj

ectiv

esLecture # 16

Finalizing 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

Intro Designing Control

Designing for Interfaces Data 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.



Design 3/24


Completing Detailed DesignDesign 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



Design 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.1Intro Designing

ControlDesigning for

Interfaces Data Access Completing the Design 5/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



Design 6/24


Designing for Interfaces

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





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





Ensure Object Model Allows Data Capture

Mediator for data captureTransaction

Account

Customer Teller



Design 9/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



Design 10/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 StorageIntro Designing




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 StorageIntro Designing




Transactiontime

customeraccount

DBMS

Objects re-assembled in memory by application and database.

Data, not objects stored.

tables

Using Relational Databases with OO

DBMS: Database Management System



Design 13/24


Objects delivered to memory for re-use.

Objects, not data, stored.

Transactiontime

customeraccount

OODBMS

tables

OO DatabasesIntro Designing




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 MaintainedIntro Designing




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



Design 16/24


Completing the Design 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



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..nRegistration



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



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



Design20/24


Consider Splitting Classes Envision system growth Leverage inheritance

properly

WinProcedureHelp

Help

WinProcedure



Design21/24


Completing Operations1. 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



Design22/24


getCategory()

showCategoryOptions()

demoExample()

WinHelpgetProblem()

match()uu

WinProceduredescribe()u

Partial Component Model

WinProcedureExampledemoExample()c

WinProblemgetCategory()

getVisible()savePrimaryParameters()showCategoryOptions()

cusc

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

categoryString

Completing WinHelp OperationsIntro Designing


Interfaces Data Access Completing the Design

23/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



Design 24/24

lecture # 16 finalizing the application design

Documents

software design

test design

detailed design ch

khalid aljasserconnecting

khalid aljasserprocess

application controlinternally

application designswe

global control