Presentation on theme: "Lecture 6: Software Design (Part I) Dr Valentina Plekhanova University of Sunderland, UK"— Presentation transcript:
Lecture 6: Software Design (Part I) Dr Valentina Plekhanova University of Sunderland, UK
Lecture 6Valentina Plekhanova 2 Design Process: Definition software design The next step after requirements analysis and specification is software design. Design design “Design is the creative process of transforming the problem into a solution; the description of a solution is also called design.” [Pfleeger, 1998] Design is a process of constructing preliminary models for producing an expected product/software/program. Design is a process of constructing preliminary models for producing an expected product/software/program. Design process Design process defines several models of the systems at different levels of abstraction.
Lecture 6Valentina Plekhanova 3 Principles of Software Design: Abstraction and Decomposition Abstraction Abstraction is an expression that shows the most important information of the program without telling its implementation details. Decomposition Decomposition is a way to divide a big task into small tasks, and to develop details of an abstraction. The benefit of decomposition is to reduce the complexity of programs.
Lecture 6Valentina Plekhanova 4 Principles of Software Design: Decomposition and Modularity high level lower level Every design method involves some kind of decomposition: starting with a high level depiction of the system’s key elements and creating lower level looks at how the system’s features and functions will fit together [Pfleeger, 1998]. Modularity module Modularity is a property that a program consists of many independent modules. A module is a modest-sized component that performs independently specific functions.
Lecture 6Valentina Plekhanova 5 Principles of Software Design: Encapsulation & Information Hiding Encapsulation Encapsulation is the grouping of related ideas into one unit, which can thereafter be referred to by a single name. Information hiding Information hiding is the use of encapsulation to restrict from external visibility certain information or implementation decisions that are internal to the encapsulation structure.
Lecture 6Valentina Plekhanova 6 Design Levels & Design Methods Design -> Abstract Design & Detailed Design Design -> Abstract Design & Detailed Design Abstract Design Abstract Design: different methods can be used, e.g. top down design, modular design, structured design, etc. Detailed Design Detailed Design, e.g. high level design, low level design.
Lecture 6Valentina Plekhanova 7 Conceptual Design & Technical Design This stage is concerned with planning how to build the software itself. Conceptual design What Conceptual design tells the customer exactly what the system will do (i.e. What? – conceptual design concentrates on the system’s functions). Technical design How Technical design allows system builders to understand the actual hardware and software needed to solve the customers’ problem (i.e. How? – technical design describes the form the system will take) [Pfleeger, 1998]
Lecture 6Valentina Plekhanova 8 Architecture Architecture Architecture associates the system capabilities identified in the requirements specification with the system components that will implement them. Components Components are usually modules, and the architecture also describes the interconnections among them.
Lecture 6Valentina Plekhanova 9 Cohesion Cohesion Cohesion is an internal property of a module - level of relationships between elements of the module. high cohesion We say that a module has high cohesion if all of its elements (e.g. procedures, statements) are related strongly in a logical way. They cooperate to achieve a common goal, which is the function of the module.
Lecture 6Valentina Plekhanova 10 Coupling Coupling Coupling characterises interrelationship among modules in a software, i.e. represents a module’s relationship to other modules. With low coupling we can analyse, modify, test, and reuse modules separately.
Lecture 6Valentina Plekhanova 11 Cohesion and Coupling CohesionCoupling Cohesion and Coupling are used for measurement of independence of elements/modules in a design, i.e. assessment of design quality [Yourdon and Constantine, 1978] goal of software engineer The goal of software engineer is to design the modules with high cohesion and low coupling.
Lecture 6Valentina Plekhanova 12 Design Methods Top down design Top down design Bottom up design Bottom up design Modular design Modular design Structured design Structured design Object oriented design Object oriented design
Lecture 6Valentina Plekhanova 13 Top-down Design Top-down design supports the abstract and decomposition principle. By this design method, a system is first abstracted as a high level unit (e.g. module, process, procedure, function), and then decomposed into low level units, possibly integrated together using some constructs.
Lecture 6Valentina Plekhanova 14 Top-down Software Design We begin by considering the problem to be computerised as a whole and identify its major components. For each component we then do the same – identify what its major sub-components are Each of the sub-components can then be broken down into its sub-components and so on, until we reach a level whereby the individual pieces can be understood and designed without any difficulty.
Lecture 6Valentina Plekhanova 15 Top-down Design top-down design stepwise refinement This process of top-down design (also called stepwise refinement) is a way to manage complexity. We are able to create user-defined functions and general procedures to carry out subtasks.
Lecture 6Valentina Plekhanova 16 Top-down Design: Reasons for Use Systemic way of breaking a large system/problem into the smaller manageable parts. Easier to understand the system/problem. Easier to test these smaller parts.
Lecture 6Valentina Plekhanova 18 Object-Oriented Design Object-oriented design Object-oriented design is a way of designing a program system by focusing on the design of objects and their integration. An object In fact, an object is a kind of module. An object is an encapsulation of attributes and operations (or methods); it takes inputs and performs some functions. In fact, an object is a kind of module. An object-oriented program can be regarded as a network of objects that interact with each other by means of sending and receiving messages (which are similar to calling methods in Java).
Lecture 6Valentina Plekhanova 19 Design Levels High Level Design High Level Design Low Level Design Low Level Design
Lecture 6Valentina Plekhanova 20 High-level Design high-level design One way to represent high-level design is to use a hierarchical structure chart where each box on the chart represents a component or subtask of the program. pseudocodestructure charts A high-level algorithm may be presented either in pseudocode or with structure charts, and it should be language independent.
Lecture 6Valentina Plekhanova 21 High Level Design: Structure Chart
Lecture 6Valentina Plekhanova 22 High Level Design High level design documents such as structure charts show: High level design documents such as structure charts show: the overall system design how the program is decomposed into separate modules which modules call which other ones how they communicate via data
Lecture 6Valentina Plekhanova 23 High Level Design they do not show: they do not show: the order in which the modules are called the number of times they are called if it’s more than once the condition(s) determining optional/conditional invocation the internal workings of the modules
Lecture 6Valentina Plekhanova 24 High-level Design High-level program design involves the identification of components of our program - task, subtasks and decisions about how information flows between them. We need to make decisions about the type of data to be used, names for variables and where to declare them (local, form-level, module or global variables), and what type of data structures and external data storage requirements are required.
Lecture 6Valentina Plekhanova 25 High-level Design At the end of high-level design we will have decided the forms, objects, procedures and functions needed and where code needs to be added to carry out the work of the program. All of these decisions may take several passes through the design process, each time round, adding more detail. It is a process of spiralling down from the requirement level to the code level - though at this stage we do not have to worry about the details of the low-level code for the procedures and functions.
Lecture 6Valentina Plekhanova 26 High-level Design: Representation We can represent out high-level design decisions by the use of a structure chart which act as a 'picture' of all the software 'parts' making up the program. Additional information can be placed on a structure chart to show the flow of data between the different parts.
Lecture 6Valentina Plekhanova 27 High-level Design: An Example Project (a,b,e,r, z, x,…) Task 1 (a,b,c,d) a,b c,d Subtask 1.1 Task 2 (e,r,t,y,p) e,r Subtask 2.1 (t,y,p,w) t,y,p Function 2.1.A w
Lecture 6Valentina Plekhanova 28 Week 8: Project Control Session Tutorial Time: 10 minutes for each Team Tutorial Time: 10 minutes for each Team Scheduledocumentation Students will present project file, particularly Schedule, plus any project documentation. Students will describe where they are in the project and any problems encountered. During the discussion reviewers will ask to see evidence of deliverables for any tasks that are complete to determine whether they have in fact been done.