CSEB233: Fundamentals of Software Engineering. Software Design

Transcription

1 CSEB233: Fundamentals of Software Engineering Software Design

2 Objectives Explain set of design principles, concepts, and practices Describe five design models complete design specification: required for a data design architectural design user interface design component-level design deployment-level design Use design support tools and evaluation Explain the use of design specification document Explain the concepts of secure software design

3 Software Design Design Principles, Concepts, and Practices

4 What is Design? Design creates software a representation or model of the But unlike the analysis provides details about: model, the design model software architecture data structures interfaces, and components that are necessary to implement the system. Why is it important? The model can be assessed for quality and improved before code is generated Tests are conducted, and more users are involved.

5 Analysis Models Design Model The four design models scenar io- based element s use-cases - text use-case diagrams activity diagrams swim lane diagrams Analysis Model f l ow- or ient ed element s data flow diagrams control-flow diagrams processing narratives Int e rf a c e De sign Com pone nt - Le v e l De sign cl ass- based element s class diagrams analysis packages CRC models collaboration diagrams behavior al element s state diagrams sequence diagrams Arc hit e c t ura l De sign Da t a / Cla ss De sign Design Model Each of the elements of the analysis/requirements model provides information that is necessary to create the design models required for a complete design specification.

6 Characteristics of Good Design Must implement all of the explicit requirements contained in the analysis model Must accommodate all the implicit requirements desired by the customer Must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software Should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective (McGlaughlin, 1991)

7 Design Principles The design process should not suffer from tunnel vision The design should be traceable to the analysis model The design should not reinvent the wheel Reinventing the wheel means to duplicate a basic method that has previously been created or optimized by others The design should minimize the intellectual distance between the software and the problem as it exists in the real world The design should exhibit uniformity and integration (Davis,1995 )

8 Design Principles The design should be structured to accommodate change The design should be structured to degrade gently, even when irregular data, events, or operating conditions are encountered The design should be assessed for quality as it is being created, not after The design should be reviewed to minimize conceptual (semantic) errors

9 Design Concepts Fundamental design concepts that span both traditional and OO software development include: Abstraction Architecture Patterns Separation of concerns Modularity Information hiding Functional Independence Refinement Aspects Refactoring OO Design concepts Design classes

10 Abstraction Use many levels of abstraction in design for a modular solution. At the highest level of abstraction, a solution is stated using the language of the problem environment At lower levels of abstraction, a more detailed description of the solution is provided. Finally, at the lowest level of abstraction, the solution is stated in a manner that can be directly implemented. Two types of abstraction: Procedural abstraction - sequence of instructions that have a specific and limited function Data abstractions - named collection of data that describes a data object

11 Abstraction door details of enter algorithm Implemented with a "knowledge" of the object that is associated with enter door manufacturer model number type swing direction weight Implemented as a data structure

12 Abstraction Data abstraction refers to, providing only essential features by hiding its background details b1 is an object calling input and output member functions. But that code is invisible to the object b1

13 Architecture Describes the overall structure of the software: organization of program components (modules), the manner in which these modules interact, and the structure of data used by the components

14 Patterns A design pattern describes a design structure that solves a particular design problem within a specific context. The objectives is to provide a description that enables a designer to determine whether the pattern: Is application to the current work Can be reused Can serve as a guide for developing a similar design pattern E.g. Online pattern searching: %2F%Fpatents.uspto.gov%2Fpatft%2Findex.html Under Quick Search, try to search pattern no and you will get automated spell analysis pattern.

15 Separation of Concerns A design concept that suggests any complex problem can be easily handled if it is sub-divided into pieces that can be solved independently A concern is a feature or behavior that is specified as part of the requirements model for the software. By separating problems into smaller, more manageable pieces, a problem takes less time and effort to solve Manifested in other design concepts: modularity, aspects, functional independence and refinement

16 Modularity When software is divided into separately named and addressable components (modules). Reasons for modularisaton: To ease the planning for implementation (coding) To define and deliver software increments To easily accommodate changes To efficiently test and debug program, and To conduct long-term maintenance without serious side effects

17 Modularity : Example vs. How many modules? Cost/module

18 Aspects Ideally, a requirements model can be organized in a way that allows you to isolate each concern so that it can be considered independently. In practice, some of these concerns span the entire system and cannot be easily compartmentalized i.e. crosscut one another. An aspect is a representation of a crosscutting concern. It is important to identify aspects so that the design can properly accommodate them as refinement and modularization occur.

19 Functional Independence Achieved by developing independent modules and aversion to excessive interaction with other modules. Module independence is measured using two quality criteria: cohesion and coupling. Cohesion is an indication of the relative functional strength of a module a cohesive module should (ideally) do just one thing Coupling is an indication of the relative interdependence among modules depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.

20 Functional Independence Cohesion:

21 Functional Independence Coupling: High and Low Coupling between Modules

22 Refinement Top down design strategy where program is developed by successively refining levels of procedural detail in a hierarchical manner. It is an elaboration process that begins at a high level of abstraction. Abstraction and refinement are complementary. While abstraction hide unnecessary details from the outsiders, refinement helps to reveal low-level detais and design progresses.

23 Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat

24 Information Hiding Suggests that modules should be specified and designed so that information (data structures and algorithm) contain within a module is inaccessible to other modules that have no need for such information Implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only necessary information

25 Information Hiding: Example Suppose we have a Time class that counts the time of day: The Display() member function prints the current time onscreen. This member function is accessible to all It is therefore declared public In contrast, the data member ticks is declared private. External users could not access it Regardless of how Display() extracts the current timestamp from ticks, users can be sure that it will do the right thing and display the correct time onscreen.

26 Refactoring Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure (Fowler, 1999) When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design. The result will be software that is easier to integrate, test and maintain.

27 Object-oriented Design Concepts Design classes Entity classes Boundary classes Controller classes Inheritance all responsibilities of a superclass is immediately inherited by all subclasses Messages stimulate some behavior to occur in the receiving object Polymorphism a characteristic that greatly reduces the effort required to extend the design

28 Design Classes As the (OO) design evolves, a set of design classes that refines the analysis classes by providing design detail is defined. Analysis classes are refined during design to become entity classes Boundary classes are developed during design to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Boundary classes are designed with the responsibility of managing the way entity objects are represented to users. Controller classes are designed to manage the creation or update of entity objects; the instantiation of boundary objects as they obtain information from entity objects; complex communication between sets of objects; validation of data communicated between objects or between the user and the application.

29 Software Design Design Models

30 Design Models high analysis model class diagrams analysis packages CRC models collaboration diagrams data flow diagrams control-flow diagrams processing narratives use-cases - text use-case diagrams activity diagrams swim lane diagrams collaboration diagrams state diagrams sequence diagrams class diagrams analysis packages CRC models collaboration diagrams data flow diagrams control-flow diagrams processing narratives state diagrams sequence diagrams Requirement s: const raint s int eroperabilit y t arget s and conf igurat ion design model low design class realizations subsystems collaboration diagrams refinements to: design class realizations subsystems collaboration diagrams technical interface design Navigation design GUI design component diagrams design classes activity diagrams sequence diagrams refinements to: component diagrams design classes activity diagrams sequence diagrams design class realizations subsystems collaboration diagrams component diagrams design classes activity diagrams sequence diagrams deployment diagrams archit ect ure element s int erface element s component -level element s process dimension deployment -level element s

31 Design Model Elements Data design elements Creates a model of data and/or information that is represented at a high level of abstraction, which is subsequently refined into progressively more implementation-specific representations that can be processes by the computer. Architectural design elements Provides high-level overview of the system with detailed descriptions to be given by other design elements Defines the relationship between major structural elements of the software, each of which will have its own architecture.

32 Design Model Elements Interface design elements Describes how the software communicates with systems that interoperate with it, and with human who use it. Component-level design elements Defines the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component or module Deployment-level design elements Indicate how software functionality and subsystems will be allocated within the physical computing environment that will support the software.

33 Data Design Elements Data modeling is the process of representing data objects and their relationships to other objects, by applying data modeling techniques. Data dictionary is the textual description of data objects and their inter-relationships. Data dictionary is commonly used in confirming data requirements and for database developers to create and maintain a database system.

34 Data Design Elements

35 Architectural Design Elements Software architecture is the structure of structures of the system, which comprise software components, the externally visible properties of those components and the relationship among them. Importance of software architecture: Enabler for communication between all parties (stakeholders) interested in the development of the software Highlights early design decisions that will have a profound impact on all software engineering work that follows Constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together

36 Architectural Styles Data-centred A data store resides at the centre and is accessed by other components that update, add and delete data. Data-flow Consisting of pipe and filters, this architecture is applied when input data are to be transformed through a series of computation components into output data. Call and return Decomposes function into a hierarchy where a main program invokes a number of program components that in turn may invoke still other components.

37 Architectural Styles Example: Architectural styles

38 Architectural Styles Object-oriented Components encapsulate data and operations, and communication and coordination between components are through message passing Layered A number of different layers are defined, each accomplishing operations that progressively become closer to the machine instruction set.

39 Component-level Design Component is a modular building block for computer software Three views of what a component is: Object-oriented view a set of collaborating classes Traditional view a functional element of a program comprising processing logic and related internal data structures and interfaces Process-related view proven reusable design or code level components made available for use as design work proceeds

40 Component-level Design

41 Interface Design Elements Three golden interface design rules of human-computer 1. Place the user in control 2. Reduce the user s memory load 3. Make the interface consistent Graphical user interface (GUI) is a collection of mechanisms defined to enable software designers to build system that implement the golden rules. Are designed following the analysis results e.g. state diagram and swimlane diagram

42 Interface Design Elements The user interface (UI)

43 Deployment-level Design Source:

44 Deployment-level Design Source:

45 Software Design Design Support Tools

46 Design Support Tools All aspects of the software engineering can be supported by software tools: from project management software through tools for business and functional analysis, system design, code storage, compilers, translation tools, test software, and so on. However, tools that are concerned with analysis and design, and with using design information to create parts (or all) of the software product, are most frequently thought of as CASE tools. List of CASE tools:

47 CASE Tool: Example IBM Rational Software Architect Source:

48 CASE Tool: Example Database Modeling: Enterprise Architect by Sparx Systems Pty Ltd. Source:

49 Design Evaluation A good software design minimizes the time required to create, modify, and maintain the software while achieving run-time performance (Shore and Chromatic, 2007) Design quality is people-sensitive. For instance, design quality is dependent upon the programmers writing and maintaining the code. Design quality is change-specific. There are two general ways to make designs of higher quality with respect to this aspect: generalizing from the tools like design patterns, and using tests and refactoring as change-enablers. (Elssamadisy, 2007)

50 Design Evaluation Modification and maintenance time are more important than creation time because time spent in maintenance is much more than creation time of a software, and in iterative development, modification happens during the initial creation of the software Design quality is unpredictable Because quality is really dependant on the team developing the software. As the team changes, or evolves, then the design quality also evolves You really only know how good a design is by its standing the test of time and modifications

51 Design Evaluation Points to ponder: To maintain the quality of the design, we must maintain the theory of the design as the programming team evolves, That design quality is tied to the people who are building and maintaining the software (Shore and Chromatic, 2007)

52 Software Design Design Specification

53 Design Specification IEEE Standard for Information Technology - Systems Design - Software Design Descriptions (IEEE ) an improved version of the 1998 version This standard specifies an organizational structure for a software design description (SDD) An SDD is a document used to specify system architecture and application design in a software related project Provides a generic template for an SDD

54 SDD: Examples Refer to m#_toc Refer to SDDSample.doc

55 Software Design Secure Software Design

56 Secure System Design Principles Saltzer [1974] and later Saltzer and Schroeder [1975] list the following design principles when creating secure programs, which are still valid: 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

57 Least privilege Each user and program should operate using the fewest privileges possible. This principle limits the damage from an accident, error, or attack. It also reduces the number of potential interactions among privileged programs, so unintentional, unwanted, or improper uses of privilege are less likely to occur. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

58 Economy of mechanism The protection system s design should be simple and small as possible. Simpler means less can go wrong; when errors occur, easier to understand and fix. Complex mechanisms may not be correctly: Understood Modeled Configured Implemented Used Keep it as simple as possible; KISS Principle 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

59 Complete mediation Every access attempt must be checked; position the mechanism so it cannot be subverted. A synonym for this goal is non-bypassability. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

60 Open design Security of a mechanism should not depend upon secrecy of its design or implementation. Security through obscurity is a bad idea Should be open for scrutiny by the community Better to have a friend/colleague find an error than a foe. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

61 Separation of privilege Access to objects should depend on more than one condition, so that defeating one protection system won t enable complete access. - Separation of duty - System should not grant permission based on single condition. - Example: Company checks over $75,000 to be signed by two officers. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

62 Least common mechanism Minimize the amount and use of shared mechanisms (e.g. use of the /tmp or /var/tmp directories). Shared objects provide potentially dangerous channels for information flow and unintended interactions. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults

63 Psychological acceptability Also known as easy to use. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults User interface must be easy to use, so that users routinely and automatically apply the mechanisms correctly. Otherwise, they will be bypassed.

64 Fail-safe defaults Also known as permission-based approach. 1. Least privilege 2. Economy of mechanism 3. Complete mediation 4. Open design 5. Separation of privilege 6. Least common mechanism 7. Psychological acceptability 8. Fail-safe defaults Unless a subject is given explicit access to an object, it should be denied access to the object.

65 Summary This module has: Introduced set of design principles, concepts, and practices Described five design models required for a complete design specification: data design, architectural design, user interface design, component-level design and deployment level design. Introduced design support tools and evaluation Introduced design specification document (SDD) Introduced secure software design

66 THE END College of Information Technology