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