Design (1) Design involves decisions on how to deliver the agreed functionality to the users. Design involves development of a clear, unambiguous and consistent user-interface. (Remember that users are already likely to have been involved in user-interface design where prototyping or some form of iterative development has been used - such as in the Agile approach) System design should be done in the context of the McCall factors, in particular - Will the software be maintainable? Will software be usable? Will software be testable? Design involves decisions on how to “package” the units of code.
Transcript
Design (1)
Design involves decisions on how to deliver the agreed functionality to the users.
Design involves development of a clear, unambiguous and consistent user-interface.
(Remember that users are already likely to have been involved in user-interface design where prototyping or some form of iterative development has been used - such as in the Agile approach)
System design should be done in the context of the McCall factors, in particular -
Will the software be maintainable?
Will software be usable?
Will software be testable?
Design involves decisions on how to “package” the units of code.
Design (2)
Large systems are always made up of smaller sub-systems.
A system architecture shows how a system is organised and how the component parts inter-operate.
Thus, the system architecture is the basic structural framework and it provides the foundation for essential communication & control between the system components.
Each sub-system or component part provides some related set of services to the user
A similar architecture is often suitable for different systems from within the same domain area – as a result of this a good architecture can support large-scale reuse.
Architecture affects performance, robustness (reliability), and maintainability of a a system
Different kinds of systems may require different architectures, e.g. transaction-processing systems, real-time systems, web-based systems
Design (3)
I will look briefly at 3 key aspects of design:
Different alternative architectures
Component-level design considerations
User interface
Design (4)
The Concept of Architecture
Get A, BLet C = A*BOutput C
Get A, B
Let C = A*B
A, B
C
C
Get A, B Let C = A*B Output C
A, B C
1 32
Design (5)
The “call-return” architecture:
A module can call one of several other modules. Control is passed to the called module
From Sommerville, “Software Engineering”
Design (6)
Example of architecture for a real-time system:
From Sommerville, “Software Engineering”
Design (7)
Architecture for a multi-processor traffic control system:
From Sommerville, “Software Engineering”
Design (8)
Weather Mapping system – an OO approach 1:
Overall architecture
From Sommerville, “Software Engineering”
Design (9)
Weather Mapping system – an OO approach 2:
Subsystems
Weather station
The architecture of each collection of objects can be modelled in turn
From Sommerville, “Software Engineering”
Design (10)
Weather Mapping system – an OO approach 3:
The Weather Station architecture
From Sommerville, “Software Engineering”
Design (11)
Weather Mapping system – an OO approach 4:
Some object classes in the weather station system
WeatherStation object class provides basic interface of weather station with its environment
This object class encapsulates all operations involving collection &sumarising of data
These object classes areconcerned with controlling hardware instruments
From Sommerville, “Software Engineering”
Design (12)
Weather Mapping system – an OO approach 5:
From the abstract to the physical – packaging components:
From Sommerville, “Software Engineering”
Design (13)
Weather Mapping system – an OO approach 6:
OO allows a consistent & seamless progression from analysis through to design:
Example
From Sommerville, “Software Engineering”
Design (14)
Architectural Design for Web-based Applications 1
From Pressman, “Software Engineering”
Design (15)
Architectural Design for Web-based Applications 2
From Pressman, “Software Engineering”
There may be a trad-off between ease of navigation and risk of confusion to unfamiliar users
There may be a trade-off between ease of navigation and risk of confusion to unfamiliar users
Component-level design considerations
Design (16)
Whether the analysis & design approach is OO or not, every effort should be made to ensure that:
all code within a module is concerned with a single discrete function
the minimum interaction between modules, i.e. we should avoid modules passing unnecessary data to one another or having read/write access to the same data
the aim is to produce software modules where all the code elements within a particular module are concerned with the execution of a single discrete task
So -
Code elements should not be bundled into the same module simply because theyrelate to operations that
happen at the same time
are the same kind of task, e.g. editing, verifying etc
“convenient” to put into one module
Temporal cohesion
Logical cohesion
Coincidental cohesion
Functional cohesion
Avoid these last 3 forms of cohesion as they have a serious negative effect on both testability and maintainability – modules should only have functional cohesion
Two modules are data coupled if all of the elements of the datapassed between these modules is used by the called module.
The data passed between modules may be a simple argument i.e. a simple variable, or it may be a data structure.
Data coupling means that a change made to one module is less likely to cause a knock-on fault in another module
All parts of a data structure must be used
Component-level design considerations Data Coupling
Design (23)
Stamp Coupling
Two modules are stamp coupled if a data structure is passed as an argument but the called module operates on only some of the individualcomponents of that data structure.
In other words, the called module doesn’t need all the data that is being passed to it
Stamp coupling slightly increases the chances of knock-on errors when changes are made to modules and it makes debugging more difficult
Component-level design considerations Data Coupling
Design (24)
Control Coupling
Two modules are control coupled if one passes an element of control to the other module; that is, one module explicitly controls the logic of the other
If module P calls module Q and Q passes a flag back to P that says: “I am unable to complete my task” then Q is passing data (i.e. data coupled).
But – if the flag means: “I am unable to complete my task and, therefore,display error message # 43” then P and Q are control coupled.
Module Q
Module P
flag
The problem here is that Module Q has to be aware of the internal structure and logic of Module P
Component-level design considerations Data Coupling
Common Coupling
Two modules arecommon coupled if both have access to the same global data area
Design (25)
Module BModule A
global_variable
The most common situation in which this arises is whenboth Module A and Module B have access to the same database and both can read and write to the database.
Both modules have read-write access to global_variable
Component-level design considerations Data Coupling
The Problems with Common Coupling -
Design (26)
As a consequence of common coupling, modules may be exposed to more data than they need. Control of data access may be more difficult and this can increase the risk of computer crime.
The introduction of new modules which can alter a global variable can result in an exponential increase in the instances of common coupling.
Module re-use becomes difficult because an identical list of global variables has to be supplied each time the module is re-used
If a maintenance change is made in one module to the declaration of a global variable then every module that can access that global variable has to be changed also.
If a run-time failure occurs it may be difficult to reconstruct what happened because any one of a number of modules could have changed the value of a variable
Component-level design considerations Data Coupling
Design (27)Content Coupling
Two modules are content coupled if a calling module directly references the code of the called module.
. . .Get pIf p = 1 then r= 1, call B (r)else if p = 2 then r = 2, call B (r) else r = 3, call B (r) endifendif
ModuleB
ModuleA
r. . . If r = 1 then do routine_1else if r = 2 then do routine_2 else do routine_3 endifendifgoto endRoutine_1 . . . . . .goto endRoutine_2 . . . . . . goto endRoutine_3 . . . . . .goto end. . . end
Module A decides which part of Module B will execute.
Content coupling is also known as pathological coupling and is the worst possible type.
Component-level design considerations Data Coupling – Diagrammatic View
Design (28)
Component-level design considerations Data Coupling
Content Coupling & Coincidental Cohesion
Software which exhibits content coupling between modules and coincidental cohesion withinmodules has no proper design structure. Such software frequently arises as a result of ongoing maintenance of legacy systems.
Design (29)
Testing, debugging and maintenance becomes increasingly more difficult and expensive.
Component re-use becomes impossible
Software becomes less stable and less reliable
User interface Design
A poorly designed user interface means that the potential benefits of the system are unlikely to be achieved.
Four key principles:
Place the user in control
Reduce the user’s memory load
Make the interface consistent
Control the use of colours
e.g. design user interaction to be Interruptible & reversible
Hide technical details from user
Design for direct interaction withobjects that appear on screen
The system should “remember” details of interaction scenarios rather than forcing the user to recall details.
Use appropriate default values
Design an interface with a consistent look, “feel” and behaviour across the whole system
Use colours to highlight & emphasise
Excessive use of colour can cause fatigue and irritation
