Design Strategies

1

Chapter 3: DESIGN STRATEGIES

By:

Mdm Azaliza binti Zainal

US Intelligence Community Agenda IC XML Implementations IC XML Standards Conclusions

2

SOFTWARE DESIGN PRACTICES AND DESIGN METHODS

Constraints That Limit Their Usefulness: • The Process Part of a Method Provides Relatively Little

Detailed Guidance as to How a Problem Should be Solved

• The Need to Use a Procedural Form Leads to Practices That Conflict with the Behaviour Observed in Experienced Designers

Roles for Software Design Methods: • Establishing Common Goals and Styles • Generating “Consistent” Documentation

�Assist With Future Maintenance �Recapture the Original Design Model

• Helping Make Some Features of a Problem More Explicit

2


3

WHY SHOULD THE SOFTWARE BE DESIGNED AT ALL?

Design is highly creative stage in software development where the designer plans

�how the system or program should meet the customer’s

�Needs. �how to make system effective and

efficient.

We can’t just throw few dozens of programmers to start programming without any detailed plans.


4

Any design problems must be tackled in three stages;

�Study and understand the problem

�Identify gross features of at least one possible solution

�Describe each abstraction used in the solution

TACKLING DESIGN PROBLEMS

3


5

Function Oriented

�Design is decomposed into set of interacting unitswhere each unit has clearly defined function

�Conceals the details of an algorithm in a function but system state information is not hidden

DESIGN METHODOLOGIES-1

The activities of this strategy;

�Data-flow design

�Structural decomposition

�Detailed design description


6

Object-oriented design � Is based on the idea of information hiding.

� System is viewed as a set of interacting objects, with their own private state.

� Dominant design strategy for new software systems.

� Objects communicate by calling on services offered by other objects rather than sharing variables. This reduces the overall system coupling.

� Message passing model allows objects to be implemented as concurrent processes.

DESIGN METHODOLOGIES-2

4


7

�Software design method:

–Principal components:

�Representation part

�Process part

�Set of heuristics @ clichés

THE ROLE OF STRATEGY IN METHODS


8

�Software designers do not arrive at a finished design immediately. They develop design iteratively through number of different versions.

� Process part

–Provides ‘procedural’ guidelines on how the models should be developed.

–Basic symbols to describe a design method:

�Oblong – to denote a representation form

�Oval – to denote a procedural step

�Arc – to denote the sequence of steps

DESIGN PROCESS

5


9 General procedural model of the software design process.

Requirements

Systems analysis

Black box model of the problem

Systems design

Detailed white box design describing the solution

GENERAL MODEL OF DESIGN PROCESS


10 Expended view of the procedural model of the software design process

Requirements

Systems analysis

Functional specification describing the problem

Architectural design

Logical design (describing solution)

Detailed design

Physical design (describing implementation)

Text

Text, Context Diagram (DFD), mathematical forms

DFDs, State charts, STDs, Structure Diagrams, class diagrams

Structure charts, Structure Diagrams, sequence diagrams, psuedocode

PROCEDURAL MODEL OF DESIGN PROCESS

6


11

�The two forms have distinctive roles and characteristics described as below: –A transformation step

�Designer modifies the structuring for their model of the system in some way.

�Reinterpreting it using a different viewpoint

�To produce a constructional model

�Require the designer to make some fairly major design decisions

–An elaboration step

�Does not involve any change of viewpoint

�More concerned with restructuring/reorganizing the design model within the current viewpoint

�To add further information to the model



12

�Transformation process

–requires the designer to be able to bridge their ideas across two or more different sets of properties.

�Elaboration process

–concern with recognizing patterns and structures


7


13

DESIGN STRATEGIES

Top-down / Decompositional Separate a Large Problem into Smaller Ones

Compositional Identifies a Set of “Entities” That Can be Modelled and Then Assembled to Create a Model for the Complete Solution

Organizational Use Where Development Organization and Management Structures Impose Constraints Upon the Design Process

Template Used Where Some General Paradigm Describes a Reasonably Large Domain of Problems


14

�Design Matrix

–To provide an abstract description of the state of the design model at any point in its evolution

–Used to describe method process

–Record opportunistic sequences of design activities

–Unite the concepts of transformation and elaboration

DESCRIBING THE DESIGN PROCESS - THE D-MATRIX

8


15

�Any design specification can be composed from the specifications for a set of ‘Design Elements’

�In Design Elements have 4 different viewpoints which is function, behaviour, data model and construction.

�In design process, there’s design model which is represented by a matrix.

THE D-MATRIX FORMALISM


16

�Measurement is fundamental to any engineering discipline. So matrices is very important for software engineering for measuring various things associated with software development. Software measures can be divided into two categories.

–Direct Measures

–Indirect Measures

MATRICES FOR SOFTWARE PRODUCTIVITY AND QUALITY

9


17

�Cost - The amount required for development

�Effort-The amount of effort required

�LOC(Lines Of Code)- The number of lines in the program

�Speed- The execution speed of the software

�Memory size-- The amount of memory need to run the software

�Errors- The number of errors

DIRECT MEASURES


18

�Function- The functionality of the software

�Quality- The quality of the software

�Complexity- The space and time complexity

�Efficiency

�Reliability

�Maintainability

INDIRECT MEASURES

10


19

SAMPLES


20

� The Five Steps 1.Understand the problem

2.Do a small example by hand

3.Write an algorithm for solving the problem

4.Translate the algorithm into a programming language (like C)

5.Test the program

� Understand the problem – What is this program supposed to do?

– The problem statement is pretty clear. The program should play this guessing game.

– What kind of information is it given? (What is the input?)

– The input is the set of player guesses, one at a time, until the player either gets the number, or runs out of guesses.

– What kind of results is it to produce? (What is the output?)

– The output is a hint after each wrong guess telling the player if their guess is too high or too low.

– What formulas or techniques will be needed?

– Most of the operation of the game is straightforward - we compare the player's guess with the stored number. One tricky thing we will have to worry about is generating the random number.

DESIGN BY TOP-DOWN DECOMPOSITION

11


21

� Write an algorithm for solving the problem

– Instead of trying to write the algorithm for the entire program, we begin by breaking up the program into modules to handle the details of different aspects of solving the task.

– We can represent this decomposition of the problem by a structure diagram:

DESIGN BY TOP-DOWN DECOMPOSITION


22

�the composite pattern is a partitioning design pattern

�composite pattern describes that a group of objects are to be treated in the same way as a single instance of an object

�to "compose" objects into tree structures to represent part-whole hierarchies

�Implementing the composite pattern lets clients treat individual objects and compositions uniformly

DESIGN BY COMPOSITION

12


23

�When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch.

�This makes code more complex, and therefore, error prone.

�The solution is an interface that allows treating complex and primitive objects uniformly.



24

�The operations you can perform on all the composite objects often have a least common denominator relationship

�For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.


13


25

�When to use

–Composite can be used when clients should ignore the difference between compositions of objects and individual objects.

–If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.



26


14


27

�Structure –Component

� is the abstraction for all components, including composite ones

�declares the interface for objects in the composition

� (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate

–Leaf

� represents leaf objects in the composition .

� implements all Component methods

–Composite

� represents a composite Component (component having children)

� implements methods to manipulate children

� implements all Component methods, generally by delegating them to its children



28

�These method is rarely used nowadays, but it will influence the company of extending or formalizing their system when used.

�Effects on company that use these methods:

–Minimum disruption of a project when staff changes occur

–A change of project manager should not lead to a change of technical direction.

–Standardization of documentation allows for better management of maintenance

ORGANIZATIONAL INFLUENCES UPON DESIGN

15


29

�Software design document has not been practiced regularly nowadays. But those who uses it, found that positive affect in the future when new staff enrolled in. The methods stated before is useful in creating an organization organized, formal and reliable.

SUMMARY


30

Q & A

THANK YOU FOR YOUR ATTENTION

☺☺☺☺

Design Strategies

Documents