software engineering lecture 10 software design: architecture, interface, procedural 1
TRANSCRIPT
![Page 1: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/1.jpg)
Software EngineeringLecture 10Software Design: Architecture, Interface, Procedural
1
![Page 2: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/2.jpg)
The Design ActivitiesArchitectural DesignInterface DesignProcedural DesignDatabase Design
2
![Page 3: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/3.jpg)
Architectural DesignDesign Concepts
◦Abstraction◦Modularity◦Control Hierarchy
3
![Page 4: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/4.jpg)
AbstractionAbstraction permits one to
concentrate on a problem at some level of generalization without regard to irrelevant low level details.
Use of abstraction also permits one to work with concepts and terms that are familiar, in the problem environment without having to transform them to an unfamiliar structure. 4
![Page 5: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/5.jpg)
Modularity A module is defined as a sub-program that is
invoked by another module. The statement are collectively referred to by
a descriptive name called the module name. A module must return to its caller i.e. have a
single entry and exit. The module should be relatively small in
size. It should be easy to read, modify and use. A module should preferably have a single
function.
5
![Page 6: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/6.jpg)
Advantages of Modularity Allow large program to be written by several or
different people. Encourage creation of commonly used routines
to be placed in library and/or be used by other programs.
Simplify overlay procedure of loading large program into main storage.
Provide more check point to measure progress. Simplify design, making program easy to modify
and reduce maintenance costs. Provide a framework for more complete testing,
easier to test. Produces well-designed and more readable
program.6
![Page 7: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/7.jpg)
Disadvantages of ModularityExecution time, compilation/loading
time and storage size requirements may be (though not always) increase.
Intermodule communication problems may be increased, due to the larger number of interfaces between parts of the software.
Demands more initial design time, since greater time would need to be spent in the architectural phase of design.
7
![Page 8: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/8.jpg)
Modularity and Software Cost
8
optimal number of modules
cost of software
number of modules
moduleintegration
cost
module development cost
![Page 9: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/9.jpg)
Control HierarchyControl Hierarchy, represents the
hierarchical organization of program components (modules) and implies a hierarchy of control.◦ Fan-Out, which is a measure of the number of modules
that are directly controlled by another module.◦ Fan-in, which indicates how many modules directly
control a given module.◦ Depth: Number of levels of control.◦ Width: Overall span of control.◦ Superordinate: i.e. a module that controls another
module.◦ Subordinate: i.e. a module that is controlled by another
module.
9
![Page 10: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/10.jpg)
Control Hierarchy
10
M
A B C
D E F G H
Depth = 2 Fan-In (A) = 1
Width = 5 Fan-Out (A) = 3
![Page 11: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/11.jpg)
Effective Modular DesignFunctional Independence
◦Is achieved by developing modules with “single minded” function and an “aversion” to excessive interaction with other modules.
Independence is measured by two qualitative criteria:◦Cohesion: a measure of relative
functional strength of a module◦Coupling: a measure of relative
interdependence among modules11
![Page 12: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/12.jpg)
Cohesion
Low Cohesion (undesirable)◦Coincidental Cohesion◦Logical Cohesion◦Temporal Cohesion
Moderate◦Procedural Cohesion◦Communicational Cohesion
High (desirable)◦One distinct task in a module (High
Cohesion)12
![Page 13: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/13.jpg)
Coupling
Low (desirable)◦Data Coupling◦Stamp Coupling
Moderate◦Control Coupling
High (undesirable)◦External Coupling◦Common Coupling◦Content Coupling
13
![Page 14: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/14.jpg)
User Interface Design
ease ofdevelop-ment
ease ofuse
14
A good UI is not easy to create, since the UI development effort is inversely proportional to the ease of use finally obtained in the software
![Page 15: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/15.jpg)
Three Golden Rules (Theo Mandel)
Place the user in controlReduce the user’s memory loadMake the interface consistent
15
![Page 16: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/16.jpg)
Place the user in controlMinimize unnecessary /
undesired actionsProvide flexible interactionProvide undoAllow customized interactionHide technical internals from the
casual userDesign direct interaction with
screen objects16
![Page 17: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/17.jpg)
Reduce the user’s memory load
Reduce demand on Short-term Memory
Establish meaningful defaultsDefine intuitive short-cutsUse real-world metaphorDisclose information in a
progressive fashion
17
![Page 18: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/18.jpg)
Make the interface consistent
Allow the user to put the current task into a meaningful context
Maintain consistency across a family of applications
If past interactive models have created user expectations, do not making unnecessary changes
18
![Page 19: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/19.jpg)
Interface Design Consideration (1)• Interface Consistency
• An inconsistent interface is often the source of frustration to the user.
• Predictability• Predictability is related to the user
model and the consistency of the interface, but emphasizes the principle of least surprise.
19
![Page 20: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/20.jpg)
Interface Design Consideration (2)• Error Handling
• A good UI minimizes the chances of an error occurring, and provides a way to recover from any error that does occur.
• Ease of Use• A UI should have on-line help and
user guidance, which are accessible when user has trouble.
20
![Page 21: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/21.jpg)
Interface Design Consideration (3)• Clarity
• Errors can be minimized if the UI communication between the UI and the user is as clear as possible.
• Feedback• Feedback to the user is important in
reducing frustration and provides reassurance that the user task is actually being carried out.
21
![Page 22: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/22.jpg)
User classificationNovices
No syntactic knowledge, little semantic knowledge of the computer usage in general
Knowledgeable, intermittent usersReasonable semantic knowledge of the application, but low recall of syntactic knowledge
Knowledgeable, frequent usersGood semantic and syntactic knowledge
22
![Page 23: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/23.jpg)
PrototypingPrototyping is one of the best known method
used to design the software interface.The prototype is evaluated by the user, who
provides the designer with direct comments about the efficacy of the interface.
If formal evaluation techniques are used (e.g. questionnaires, rating sheets), the designer may extract information from these data.
Design modification are made based on user input and the next level of prototype is created.
The evaluation cycle continues until no further modification to the interface design are necessary.
23
![Page 24: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/24.jpg)
Procedural DesignGraphical Design Notation: Flow-chartTabular Design Notation: Decision TableProgram Design Language (PDL)
At the component level, the software engineer must represent data structures, interfaces, and algorithms in sufficient detail to guide the generation of programming language source-code.
24
![Page 25: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/25.jpg)
Flow-Chart Boxes to indicate processing
steps. Diamond to indicate logical
conditions. Arrows to indicate flow of control. Two boxes connected by a line of
control will indicate a Sequence.
25
![Page 26: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/26.jpg)
Flow-Chart Example
26
![Page 27: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/27.jpg)
Decision TableProvides a notation that
translates actions and conditions (described in a processing narrative) into a tabular form. The upper left-hand section contains a list
of all conditions. The lower left-hand section lists all actions
that are possible based on the conditions. The right-hand sections form a matrix that
indicates condition combinations and the corresponding actions that will occur for a specific combination
27
![Page 28: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/28.jpg)
Decision Table Example
28
![Page 29: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/29.jpg)
Program Design Language Program Design Language (PDL)
is also called structured English, or Pseudocode.
PDL have the following characteristics: A fixed syntax of keywords that provide for all
structured constructs, data declaration, and modularity characteristics
A free syntax of natural language that describes processing features
Data declaration facilities that should include both simple (scalar, array) and complex (linked list or tree) data structures.
Subprogram definition and calling techniques that support various methods of interface description
29
![Page 30: Software Engineering Lecture 10 Software Design: Architecture, Interface, Procedural 1](https://reader036.vdocuments.mx/reader036/viewer/2022062307/551b0a705503465e7d8b5cc1/html5/thumbnails/30.jpg)
ReferencesPressman, Chapter 13-16
30