487-390 Main 487-371 Rice 1 487-390 Main 487-371 Rice 2 3 - - PowerPoint PPT Presentation

1

487-390 Main 487-371 Rice

2

487-390 Main 487-371 Rice

3

4

• Data Design

– Transform the information domain (created in analysis) into Data structures.

• Architectural Design:

– Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal

• Interfaces Design - How the system interfaces:

– With itself (procedure calls) – With other systems – With users (Screens)

• Components Design

– Structural elements into procedural description

5

• Abstraction - Each step of the SW process

refines the solution and removes levels of abstraction:

– High level – user and environment – Low levels – code

6

• Describes:

– the structure of a program:

• how the modules interact

– the structure of the data.

7

• Organization of the modules within a

program

– Does not show sequence of processes – It shows how modules call each other

• Hierarchy of Control
• TreeLike Notation

– Represents hierarchical control for call and return architecture (example Pressman Page 347)

8

• A good module has functional

independence.

• It is achieved by developing modules with

"single-minded" function

• Functional Independence is measured

by looking at the cohesion and coupling

• f the modules.

9

• Each module should have a central theme or

purpose.

– Should be able to describe a cohesive module using a sentence with one subject and one verb

• High cohesion is good. Low cohesion is to be

avoided.

10

• Coincidentally cohesive (worst):

– module performs tasks that are related loosely or maybe not at all. – Example: divide the monolithic program into modules using a ruler

• Logically Cohesive (low):

– Logically related tasks in one module – Example: A module that does all errors processing tasks.

• Temporal cohesion (low):

– tasks of a module are related because they must be executed in the same time span. – Example: Clean up tasks at the end of processing

11

• Communicational cohesion (moderate):

– all processing elements concentrate on one area

• f a data structure.

– Update the record in the database and add to audit trial.

– module performs one distinct task. – Example: a Procedure that computes the shipping cost of an order.

12

• Refers to the degree of

interconnectedness between modules

• Minimize coupling to reduce the ripple

effect when changes are made.

• The goal is to reduce connection paths

between modules.

• High coupling limits reuse.
• lowest possible coupling

13

• Data coupling (low):

– Only simple data items are passed

• Stamp coupling (low):

– A structure is passed, even though only a portion of the data items are needed.

• Control coupling (moderate):

– a "control flag", variable that controls decisions in a subordinate or super-ordinate module is passed.

• External coupling (high):

– modules are tied to an environment. I/O ties modules to a specific device, formats and communication protocols.

14

• Common coupling (high)

– modules reference a global data area.

• Content coupling (highest):

– when one module makes use of data or control information maintained within the boundary of another module.

• This should always be avoided

15

• Data Design

– Transform the information domain (created in analysis) into Data structures.

• Architectural Design:

– Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal

• Interfaces Design - How the system interfaces:

– With itself (procedure calls) – With other systems – With users (Screens)

• Components Design

– Structural elements into procedural description

16

Chapter 14

17

• To View and Evaluate the system as a

whole before moving to component design.

– Blueprint of a house

• 1st the foot print of the house is designed
• Then plumping and electrical plans are drawn.

18

• Data Design

– Transforms data elements in the Requirement Specification (ERD, data dictionary) into data structures. – Represent the data component of the architecture

• Architectural Design

– Define a family of system in terms of a pattern of structural organization

• i.e. Ranch vs. Victorian House.

– Focuses on the structure of the SW components

• Properties and
• interactions

19

Approaches to Selecting an Architectural Design for a system

• Analyze the needs of the system

– Requirements, – Constraints, and the – Environment

• Evaluate different architectures

– Pick the best

• Map requirements of your system into the

selected architecture.

20

• Is a pattern for construction:

– Should guide the builder – Ranch style, Victorian Style will give you a general idea on the architecture of the system – Each style encompasses a set of Categories

21

• They Define the Architectural Style:

– Components that perform a function

• Database, simple computational modules, clients, servers and

filters.

– Connectors, enable communications

• Define how the components communicate, coordinate and

cooperate

– Call, event broadcasting, pipes

– Constraints

• Define how the system can be integrated

– Semantic Models

• Specify how to determine a system’s overall properties from

the properties of its parts.

22

• Data Flow Systems: (Figure Page 373 )

– Batch Sequential – Pipes and Filters

• Call-and-Return systems

– Main program and sub-programs – Object Oriented Systems – Hierarchical layers

23

• Independent Components:

– Communication Processes – Event Systems

• Virtual Machines

– Interpreters – Rule based Systems

• Data-Centered Systems (Figure on page 372):

– Databases – HTML Systems

24

• Components : Filters

– Each Filter transforms the data

• Connectors : Pipes

– Transmit data from one filter to the next

• Constraints :

– Each Filter works independently – Each filter expects Input and should produce Output.

• Page 373 for Model

25

• Is a Pipes and Filters model with ONE flow
• Page 373 for Model

26

• Components : Main and Sub-Components
• Communication : Main calls sub-programs
• Constraints : Main act as a Driver

Main Sub2 Sub1

27

• Components: Database elements (tables,

queries, etc.)

• Communication: Relationships
• Constraints : Client request info from

Server

28

• Data Design

– Transform the information domain (created in analysis) into Data structures.

• Architectural Design:

– Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal

• Interfaces Design – (Chapter 13) How the system

interfaces:

– With itself (procedure calls) – With other systems – With users (Screens)

• Components Design

– Structural elements into procedural description

29

• User Model

– Depicts the profile of end users – Should be related to user characteristics:

• Age
• Gender
• Education
• Special Needs

– Types of users:

• Knowledgeable frequent
• Knowledgeable infrequent
• Never seen a computer before

30

• Design Issues:

– Response Time – Help Facility – Error Messages

• Expressed in user terms
• Extended help for action
• Provide more info on sequences
• Non-Judgmental

– Command Labeling

• menus

31

• Guidelines

– Be Consistent – Easy to use screens - Be SIMPLE – Offer Meaningful feedback – Permit easy reversal of most actions – Reduce the amount of information that must be memorized

• Use Pull-down-menus

– Keep help at all levels

32

• Guidelines

– Meaningful Titles – Get user feedback

• Listen to users
• Ask for suggestions
• Prototype and get feedback again and again until the

user says “This is the best”

• Don’t be too technical

33

• Data Design

– Transform the information domain (created in analysis) into Data structures.

• Architectural Design:

– Defines the relationship between major structural elements of the software. – The design patterns that can be used to achieve the goal

• Interfaces Design - How the system interfaces:

– With itself (procedure calls) – With other systems – With users (Screens)

• Components Level Design (Chapter 16)

– Structural elements into procedural description

34

• Also known as Procedural Design
• The intent is to translate the design model into

code like language.

• Represent the design at a level of abstraction that

is close to Code

ARCHITECTURE DATA INTERFACES

PROCEDURAL DESIGN

35

• Establish the algorithmic detail required to:

– Manipulate data structures – Define components interfaces – Implement the processing algorithms for each component.

• Its an opportunity to verify your design

correctness

36

• Graphical

– Flowchart (Page 425)

• Tabular Design Notation

– Decision Table (Page 429)

• Text

– Program Design Language “Pseudo-Code” (Page 431)

37

• Title Page

– Title, – Team Members Indicate Team Leader and – Logo.

• 1. Introduction and Scope

1.1 Goals and objectives Overall goals and software objectives are described. 1.2 Statement of scope A description of the software is presented. Major inputs, processing functionality, and outputs are described without regard to implementation detail. 1.3 Software context The software is placed in a business or product line

• context. Strategic issues relevant to context are discussed. The intent is

for the reader to understand the 'big picture'. 1.4 Major constraints Any business or product line constraints that will impact the manner in which the software is to be specified, designed, implemented or tested are noted here.

38

2. Data Design

A description of all data structures including internal, global, and temporary data structures.

2.1 Internal software data structure

Data structures that are passed among components of the software are described.

2.2 Global data structure

Data structures that are available to major portions of the architecture are described.

2.3 Temporary data structure

Files created for interim use are described.

2.4 Database description

Database(s) created as part of the application is(are) described.

39

3. Architectural and component-level design

A description of the program architecture is presented.

3.1 Program Structure

A detailed description the program structure chosen for the application is presented.

3.1.1 Architecture diagram

A pictorial representation of the architecture is presented.

40

3.2 Components Description

3.2.1 For each Module in your SW Architecture complete a PSPEC 3.2.2 Component Level Design For each Module: Module ID: Module Name: Input : Output Modifies: Is-called-by: Calls: Algorithmic Model (PDL,Flowcharts) Local Data Structures:

41

4. User interface design

A description of the user interface design of the software is presented.

4.1 Description of the user interface

A detailed description of user interface including screen images or prototype is presented.

4.1.1 Screen images

Representation of the interface form the user's point of view.

4.1.2 Objects and actions

All screen objects and actions are identified.

4.2 Interface design rules

Conventions and standards used for designing/implementing the user interface are stated.

42

5.0 Testing Issues

Test strategy and preliminary test case specification are presented in this section.

5.1 Classes of tests

The types of tests to be conducted are specified, including as much detail as is possible at this stage. Emphasis here is on black-box and white-box testing.

5.2 Expected software response

The expected results from testing are specified. Begin to think of test cases and what the results should be. Test cases can be for individual modules (white box testing) or the overall system (black box testing).

5.3 Performance bounds

Special performance requirements are specified.

5.4 Identification of critical components

Those components that are critical and demand particular attention during testing are identified.

43

• Code is generated in this Phase
• The information in the design document is

translated to CODE.

44

Analysis Analysis Design Design Code Code Test Test Implementation

45

• Performs Functionality
• Readable
• Meaningful Comments
• Easy To Maintain
• Understand-Able

46

• 1. Through the use of Structured Coding

– Sequence – One task after the other – Condition – IF Statement – Repetition – Looping

47

Private Sub Command0_Click() On Error GoTo Err_Command0_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "frmSchedule" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command0_Click: Exit Sub Err_Command0_Click: MsgBox Err.Description Resume Exit_Command0_Click End Sub If X=0 Then { X = X +1 Else X = X –1 }

For (pnode = linklist :: first() ; pnode; pnode = pnode- >next()) { total_sales += pnode->ret_num; }

48

Private Sub Command0_Click() On Error GoTo Err_Command0_Click Dim stDocName As String Dim stLinkCriteria As String stDocName = "frmSchedule" DoCmd.OpenForm stDocName, , , stLinkCriteria Exit_Command0_Click: Exit Sub Err_Command0_Click: MsgBox Err.Description Resume Exit_Command0_Click End Sub

If X=0 Then {X = X +1 Else X = X –1 }

For (pnode = linklist :: first() ; pnode; pnode = pnode- >next()){total_sales += pnode->ret_num;}

49

• 3. Through Good Program Documentation
• Program Header
• Program Name
• Date : first development date
• Description
• Assumptions
• Changed History:
• Avoid same line documentation
• Make meaningful comments

50

3. Through Good Program Documentation Bad Example

If (linklist::getcount () > 0 ) /* if getcount >0,compute value)*/ return Total_Sales; Else return0;

Good Example

/* if List empty return 0, otherwise compute total sales */ If (linklist::getcount () > 0 ) return Total_Sales; Else return0;

51

• 4. Use Meaningful Variable Names

Bad Example

Int X, float Y;

Good Example

Int Total_sales; /* accumulate the sum of all sales */ Float count; /* Count all number in the list */

52

• 5. Have Code Standards and enforce it during

Code Review