1

1

Meltem Özturan

misprivate.boun.edu.tr/ozturan/mis515

2

2

3

System Design

System design is the process of organizing and

structuring the components of a system to allow the

construction of the new system.

Various components need to be designed during

system design, including the user interface, the

application programs, the database, and the network.

The outputs of systems analysis phase (models and

documents) are used as inputs to design phase.

There are two levels in system design;

1. General Design : Overall structure and form of the

solution

2. Detail Design : Includes the design of specific details

4

Moving to Design – General Design

The outputs of the design are also a set of diagrams, or

models, that describe the architecture of the new

system and the detailed logic within the various

programming components.

The inputs, design activities, and outputs are different

depending on whether a structured approach or an

object-orinted approach is used.

3

5

Moving to Design – Structured Approach• System Flowchart• System flow chart is the computer system

representation of various computer programs, files, databases and associated manual procedures

• Processes are grouped into programs and subsystems based on similarities such as processes performed monthly, processes that update employee data. They include common flow of data, controls interaction with permanent data stores

• The system flow charts are used primarily to describe large information systems consisting of distinct subsystems and many programs. Such systems involve processing that can be divided into discrete steps. Files may be used instead of (or in addition) the databases

6

Moving to Design – Structured Approach• System Flowchart• In today’s newer systems much processing is real

time (or a combination of both real time and batch components. System flow charts may be used for those systems (they show the relationship between real-time components and batch processing components)

• • System flow charts show inputs and outputs, more focused on physical implementation and descriptions of file mediums, disks and tapes

4

7FIGURE 9-7 Common system flow chart symbols.

Moving to Design – Structured Approach

System flow chart symbols

8

Moving to Design – Structured Approach

• Structure chart• A hierarchical diagram showing the relationships

between the modules of a computer program

• The objective of structured design is to create a

top-down decomposition of the functions to be

performed by a given program in a system – use a

structure chart to show this

• Uses rectangles to represent each such module

(the basic component of a structure chart

• Higher-level modules are “control” modules that

control flow of execution (call lower level modules

which are the “worker bee” modules that contain

program logic)

5

9

• Structure chart characteristics (Based on idea of modular and top-down programming)

• Breaking a complex problem down into smaller modules

• Modules are well formed with high internal cohesiveness and minimum data coupling

• Vertical lines connecting the modules indicate calling structure

• Little arrows next to the lines show the data passed between modules (inputs and outputs)

• Data couples: individual items that passes between modules

• Program call: the transfer of control from a module to a subordinate module to perform a requested service (can be implemented as e.g. a function or procedure call)

10

• Structure chart symbols• Rectangles represent modules

• Can represent a function (e.g. C), a procedure (e.g. Pascal), a paragraph (e.g. COBOL) , subroutine (e.g. FORTRAN) etc.

• Rectangle with double bars represents a module used several places (optional)

• Little arrows with open circles represent data couples

• Little arrows with closed circles represent control couple flag (e.g. end of file flag)

• Curved arrows immediately below a boss module represents iteration (looping)

• Darkened diamond represents a conditional call to lower modules

6

11

Structure Chart

Symbols

12

Notes on Structure Chart

• Each module does a very specific function

• Module at top of the tree is the boss module• Function is to call modules on level below, pass

information to them

• Middle level modules control the modules below • Call them and pass data

• At the very bottom, the leaves contain the actual algorithms to carry out the program functions

• Call of modules is left to right across the tree

7

13

Developing a Structure Chart

• Transaction analysis• The development of a structure chart based on a

DFD that describes the processing for several types of transactions

• Uses as input the system flow chart and the event table to develop the top level of the tree in a structure chart

• Transform analysis• The development of a structure chart based on a

DFD that describes the input-process-output data flow

• Used to develop the subtrees in a structure chart –one for each event in the program

14

Transaction Analysis

• First step is to identify the major programs

• Can do by looking a the system flow chart and

identifying the major programs

• For a subsystem or program we want to make

a structure chart for, we can look a the event-

partitioned DFD to identify the major

processes

• These major processes will become the modules

in the resulting high level structure chart

8

15

Transform Analysis

• Based on idea that computer program “transforms” input data into output data

• Structure charts developed with transform analysis usually have 3 main subtrees• Input subtree to get data

• A calculate subtree to perform logic

• An output subtree to write the results

• Can create by rearranging elements from• DFD fragment for an event

• The detailed DFD for that event

16

Steps for creating the structure chart from the DFD

1. Identify the primary information flow

2. Find the process that represents the most

fundamental change from an input stream

to an output stream – the central transform

• Afferent data flow: the incoming data flow in a

sequential set of process bubbles

• Efferent data flow: the outgoing data flow from a

sequential set of process bubbles

• Central transform: the central processing

bubbles in a transform analysis type of data flow

9

17

Steps for creating the structure chart from the DFD

3. Redraw the data flow diagram (DFD) with

• The inputs to the left

• The central transform process in the middle

• The outputs to the right

• The parent process above the central transform

process See next slide

4. Generate the first-draft structure chart

including data couples

18

5. Add other modules as necessary to• Get input data via the user-interface screens

• Read and write to the data stores

• Write output data or reports

6. Using structured English or decision table documentation, add any other required intermediate relationships

7. Make the final refinements to the structure chart based on quality control concepts

Steps for creating the structure chart from the DFD

10

19

Evaluating the Quality of a Structure Chart

• Module coupling•The manner in which modules relate to each other

• Desirable to have loosely coupled modules Have modules as independent as possible, module does not need to know who invoked it

• Best coupling is through simple data coupling• The module is called and a specific set of data items is

passed

• Module function performs its function and returns the output

• Calling module does not need to know about processing details of function called

20

• Cohesion• Refers to the degree to which all of the code within

a module contributes to implementing one well-defined task

• Desirable to have modules with high cohesion implementing a single function• Modules that implement a single task tend to have

relatively low coupling because all of their internal code acts on the same data item(s)

• Modules with poor cohesion tend to have high coupling because loosely related tasks are typically performed on different data items across modules

• A flag passed down the structure chart is an indicator of poor cohesion

Evaluating the Quality of a Structure Chart

11

21

Module Algorithm Design

• Describe the internal logic within each module

using any one of the below methods:

• Three methods

• Flow charts

• Structured English

• Pseudocode (variation of structured English

similar to programming language that will be

used – e.g. COBOL like or C like pseudocode)

• Sequence

• Decisions

• Iteration

22

Integration of the Structured Application Design with User-

Interface Design, Database Design and Network Design• Before the structure chart is complete, it is usually

modified to integrate design of• User interface

• User interface consists of input forms, interactive input/output forms and output forms or reports –must ask

• Do additional user-interface modules need to be added?

• Does the pseudocode in the interface module need to be changed?

• Do additional data couples need to be added?• The database

• Information in every data store must be somewhere in the database

• The network• Must evaluate which functions will be executing on

which nodes of the network

12

23

• Object-oriented design models provide the

bridge between the object-oriented analysis

models and the object-oriented program

• Object-oriented programs

• Basic concept: the program consists of a set of

program objects that cooperate to accomplish a

result

• Objects work together by sending messages

• Example: in a graphical user interface (GUI)

windows and menus etc. are objects. If you click

on a window object a message is sent to display

itself (e.g. window, a menu bar etc.)

Moving to Design – OO Approach

24

OO Models

•Package diagram

•Design class diagram with methods

•Method pseudocode

Object-Oriented Models

13

25

Package Diagrams

• Package diagram: a high-level diagram that identifies the major components of a system

• Objective• Identify the major components (subsystems) of a

system

• Only two symbols• A tabbed rectangle – identifies the major system

and subsystems• A dashed arrow – a dependency arrow with the

tail connected to the package that is dependent• Dependency means that the structure and code in one

package is dependent on another (e.g. may use data structures from there)

• Developed from decision how to best partition the system

26

Package Diagrams

• Can expand the diagrams to show what classes are contained in the subsystems depicted (classes are plain rectangles – no tabs)

• Also can show dependencies across different packages

14

27

Design Class Diagrams

• Design class diagram

• A class diagram with notation to describe design

components within the classes

• It is a variation on the class diagram (class

diagram shows a set of classes and relationships)

• During analysis we didn’t care as much about the

attributes and methods of classes, now in design

we do want to fill in that information

• Design class diagram is really the class diagram

expanded

28

Design Class Diagrams

• The format for design classes

• Name of the class is in the top compartment (also the

name of a superclass if appropriate)

• Attribute list

• List of methods

- Method signature

- Method procedure

15

29

Design Class Diagram

30

Design Class Diagram Development

• First step• Decide on the class to be designed• Elaborate the attribute list as much as possible

• Second step• Find all the methods that belong to this class

• One way is to simply look through the sequence diagrams and find all the messages going to the class

• create a method corresponding to each messagederived from the state chart

• Final step• Elaborate the methods with logic• Use information from the state chart for this• A transition is fired by a “trigger” in the state chart• Method logic comes from: decision logic in state chart,

the body of the method from the action-expression in the state chart

16

31

Method Development and Pseudocode

• The detailed logic for the method derives from the action statements associated with the transitions (from state to state) in the state chart

• Each transition in the state chart identifies a method

• There are different forms for action statements, including• English statements, dot notation, entry/, do/, and

exit/

• During development of class methods the logic is documented using pseudocode

32

Integrating the Object-oriented application design with user

interface design, database design and network design

Regarding the user interface

• Since the OO design results in a set of independent

interacting classes the overall structure of the system will not

change due to the user interface

• A set of interface classes are designed and added to the

overall class diagram

• There are many already built tools and libraries of

components that can be used with OO interface design

• Can involve selecting a library of tools, designing reports and

forms and inserting logic within the methods to access them

• Design of the application classes is best done in conjunction

with the design of the user interface

17

33

• Regarding the database• Database access is usually provided through a set of

database classes

• Some OO languages can automatically read and write to the

database, while others require specific calls to database

interface objects

• Identifying the target language and database system is

important in order that appropriate integration can be done

during design

• Regarding networks• Object-oriented applications frequently execute in a

distributed environment

• Individual objects (or classes) can be assigned to separate

nodes

• However, appropriate middleware will be necessary to

ensure there is no conflicts between objects

34

Need for Project Coordination

• Coordinating all the activities during design

can be difficult

• Many business rules may have to be

incorporated in the system

• Management may still be making decisions

while the project is being developed

• Projects begin to fragment based on number

of design issues to be addressed

18

35

• The system may need to be subdivided into

subsystems

• Each subsystem may have its own unique design

requirements

• The project team may be divided into smaller

teams to focus on the various subsystem

• Some technical issues (e.g. network configuration,

database design etc.) may be common to all

subsystems

• Others (e.g. response time etc.) may be limited to

specific subsystems

• All of these teams will need to be coordinated

36

• Two mini projects may be initiated at this point• Data conversion project• Test case development project

• Activities of implementation phase, such as programming, begin around this time

• Often design and programming may be conducted concurrently

• Other complications• In addition to groups working on design issues,

groups of programmers may also be getting added to the team

• Also people may be working at different locations• Communication becomes exponentially more

complicated as more people get added!• Project management tools and techniques

are needed

19

37

Coordinating Project Teams

• Fundamental tool in coordinating activities of the

project team is the project schedule

• The project manager must update the project

schedule as time goes by

• During the analysis phase project management is

often done by the project manager and an assistant.

• Once the project expands and several teams are

formed a committee may be formed of the leaders of

the key design and implementation teams and may

carry out more of the coordination and control

• Weekly and sometimes daily status meetings

may be held

38

Coordinating Information

• Development of design models generates a great

amount of detail

• Modules, classes, data fields, data structures, forms,

reports, methods, subroutine details are defined in

detail

• Takes a lot of coordination to keep track of all the

information

• Two kinds of tools help

• CASE tools (with a central repository to capture information)

• Central repository allows all teams to view project

information (see next slide)

20

39

Case Repository

40

• Other electronic tools to help with team

communication and information coordination

• Computer support for collaborative work (CSCW)

• Allows for team members to work on and dynamically update

working documents or diagrams

• One such system is Lotus Notes

• A difficult part of the development project is to keep

track of open items and unresolved issues

• Can have an “open items control log”

• A sequential list of all open items with information to track

responsibilities and resolution of the open items