Software Design and

Architecture
Instructor: Mr. Muhammad Asim
Outline
 Motivations
 Informal requirements
 Data flow diagram
 State transition diagram
 State transition table
 Z (discussion) (excluded part yet)
Motivations
 The goal of software design is to build a model that meets all
customer requirements and leads to successful implementation.
 As software systems continue to grow in scale, complexity, and
distribution, their proper design becomes extremely important in
software production.
 Any software, regardless of its application domain, should have an
overall architecture design that guides its construction and
development.
 The success of a software product or system largely depends on
the success of its architecture design.
Motivations
 When is software design conducted? Software design is an early
phase of the Software Development Life Cycle (SDLC). During this
phase, software designers model the system and assess its quality
so that improvements may be made before the software goes into
the production phase.
 SDLC consists of the following stages: software requirements
analysis; software design (architecture and detailed); software
development and implementation; and testing and quality
assurance, maintenance, and evolution.
 The Software Requirements Specification (SRS) provides the input
necessary for design. SRS is the result of requirements analysis; it
records the functional and nonfunctional requirements that must be
met by the software system.
 Here is the first trivial example to illustrate the progression
from informal to formal description.
Informal requirements
 The purpose of this program is to ensure that patients are treated
correctly, as directed by their prescriptions.
 Many therapy machine settings must be set properly to deliver
each prescribed treatment.
 Console program ensure that radiation beam can only tern-on
when the correct setting have been achieved.
 Console computer stores the database of prescriptions for many
patients.
 Each patient’s prescription include different beam configurations
called fields. Each field is described by many machine setting.
 Therapist select different console operations by pressing labelled
function keys (Figure 6.2).
Informal requirements (cont.…)
 Informal requirements (cont.…)
 The therapist tern the beam on or off by pressing buttons on separate
control panel. These buttons are not control by computer.
 The control program is only responsible for checking that the prescribed
setting s and actual settings agree.
 When a patient arrives, the therapist presses SELECT PATIENT key
display the list of patients whose prescription is on file, therapist conforms
the selection by pressing ENTER.
 Then the list of beams for that patients appears, he chooses one and again
presses ENTER.
 After it, therapist adjust patient position and setup machine.
 When all the setting match the prescription, workstation display machine is
ready to begin a treatment.
Informal requirements (cont.…)
 Therapist presses the START button and beam turns on. Then
tern of auto by the completion of prescribed dose.
 If he want to tern off the beams in some sudden situation,
therapist press STOP button.
 If any fault is detected, control program will open their
relays, this will also tern off the beam.
Data flow diagram
Data flow diagram (cont.…)
 This diagram described a way to organize the internal
structure of control program but we can’t use it for prediction
analysis of its behavior.
 It has tittle formal content (bubbles, arrows and boxes).
 There is not much, to help us decide if this diagram describes
a good design. Clearly we need more.
 We seem to have pushed most of the work into that bubble
labelled CONTROL. What’s going on in there?
 Its behavior description gap.
State transition diagram
 A state transition diagram – look not so different but this
diagram is much more powerful.
 It’s a finite state machine model. It models the behavior of the
control program not its structure.
 Bubbles represent states – Arrow represent transition.
 Arrows are labelled with the event that cause state transition.
 In the PATIENTS state pressing the ENTER key cause a
transition to the FIELD state, but in the FIELD state pressing
ENTER bring you the SETUP.
 By it requirements can be modeled by a machine by just a few
states.
State transition diagram
State transition diagram (cont.…)
State transition table
State transition table (cont.…)
Z (discussion)