Design engineering - PowerPoint Presentation

Slide1

Design engineering

Vilnius

2015Slide2

The goal of design engineering is to produce a model that exhibits:firmness – a program should not have bugs that inhibit its function;c

ommodity – a program should be suitable for purposes for which it was intended;delight

– the experience of using the program should be a pleasurable one.Slide3

Accomplished by practicing diversification and convergencediversification

– acquisition of alternatives (design material, i.e. components, component solutions, knowledge);convergence

– picking and choosing elements from the alternatives that meet the requirements defined by requirements engineering and analysis model.Slide4

Each of the element of analysis model provide necessary information for the four design models required for design specification:data/class design;architectural design;interface design;

component design.Slide5

Characteristics that serve as a guide for the evaluation of a good designThe design must implement all of the explicit requirements contained in analysis model and implicit requirements desired by customer.Design must be readable and understandable by implementers, testers and maintainers alike.

Design should provide complete picture of the software, addressing functional, behavioral and data domains from an implementation perspective.Slide6

What criteria would help to evaluate design quality?Slide7

Technical criteria for evaluation of design quality (1)A design should exhibit an architecture that:

has been created using recognizable architectural styles and patterns;

is composed of components that exhibit good design characteristics;

can be designed in evolutionary fashion.Slide8

A design should be modular.A design should contain distinct representation of data, architecture, interfaces, and components.

A design should lead to data structures that are appropriate for classes to be implemented and are drawn from recognizable patterns.A design should lead to components that exhibit independent functional characteristics.

Technical criteria for evaluation of design quality (2)Slide9

A design should lead to interfaces that reduce the complexity of connections between components and with external environment.A design should be derived using a repeatable method that is driven by information obtained during software requirements analysis.

A design should be represented using a notation that effectively communicates its meaning.

Technical criteria for evaluation of design quality (3)Slide10

Software quality attributes!?

Huh?Slide11

Software quality attributes (FURPS)FunctionalityUsabilityReliabilityPerformanceSupportabilitySlide12

Design concepts“The Beginning of wisdom for a [software engineer] is to recognize the difference between getting a program to work, and getting it right.”

M. A. JacksonSlide13

Abstractionfor modular solution many levels of abstraction can be posed;at highest level solution is stated in broad terms using language terms of problem environment;

at lower levels a more detailed description is provided; procedural abstraction refers to a sequence of instructions that have a specific an limited function;

data abstraction is a named collection of data that describes a data object.Slide14

Architecture (1)Is the structure/organization of program components (modules), the manner in which these components interact, and the structure of data that is used by the components.Components can be generalized to represent major system elements and their interactions.

Goal – derive architectural rendering of system, that serves as a framework from which more detailed design activities are conducted.Slide15

Architecture (2)Architectural design models:structural models;framework models;dynamic models;

process models;functional models.Slide16

PatternsDescribes a design structure that solves a particular design problem within a specific context.Should provide description that enables designer to determine:

whether pattern is applicable to current work;whether the pattern can be reused;

whether the pattern can serve as a guide for developing similar, but functionally or structurally different pattern.Slide17

ModularityMonolithic software cannot be easily grasped by a software engineer.It takes more time to solve more difficult problem.

“divide an conquer” strategy – it’s easier to solve complex problem when you break it into manageable pieces.Slide18

Should we subdivide indefinitely?If not how small is too small?

?Slide19

As the number of modules grows, the effort (cost) associated with integrating the modules also grows!Slide20

Information hidingBuilds up on modularity concept.Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information;

Hiding defines and enforces access constraints to procedural details and local data structures used within a module.

Hiding prevents error propagation outside of a module.Slide21

Functional independenceEach module should address a specific sub function of requirements and have a simple interface.Functional independent modules are easier to develop, maintain, and test;

Error propagation is reduced and reusable modules are possible;Assessed using two qualitative criteria:

cohesion;

coupling.Slide22

RefinementA top-down design strategy by which program is designed by successively refining levels of procedural detail;Abstraction and refinement are complementary features:

one specifies procedure and data without details;

o

ther allows to elaborate by providing low-level details.Slide23

RefactoringIt is the process of changing a software system in such way that it does not alter the external behavior of the code yet improves its internal structure.Slide24

Design classesSoftware team must define a set of design classes that:refine the analysis classes by providing design detail that will enable the classes to be implemented;

create a new set of design classes that implement a software infrastructure to support the business solution.Slide25

Different types of design classes representing a different layer of design architecture:user interface classes;

business domain classes;process classes;

persistent classes;

system classes.Slide26

What are the characteristics of well formed design classes?Slide27

Characteristics of well formed design classesComplete and sufficient

PrimitivenessHigh cohesionLow couplingSlide28

Design modelThe elements of design model use many of the same UML diagrams that were used in the analysis model.The diagrams are refined and elaborated – more implementation specific detail is provided;Architectural structure and style, components that reside within architecture, interfaces between components and with outside world are all emphasized.Slide29
Slide30

Design model elementsData design elements

Architectural design elementsInterface design elements

The user interface (UI)

External interfaces

Internal interfaces between various design components

Component-level design elements

Deployment-level design elementsSlide31

Types of design patterns considered at various levels of abstractionArchitectural patterns(Peer-to-peer, Service-oriented architecture, etc.)

Design patterns

(Iterator, Scheduler, Thread pool, Wrapper, etc.)

Idioms

(Infinite loop, swapping values between variables, etc.)Slide32

FrameworksProvides an implementation-specific skeletal infrastructure for design work.It is not a design pattern, but rather a skeleton with a collection of “plug points” that enable it to be adapted to a specific problem domain.

The plug points enable designer to integrate problem specific classes or functionality within the skeleton.Slide33

?