NCC Education Pod Cast PowerPoint Presentationstaff.um.edu.mt/ecac1/files/gozo/SEF-3.pdfUniversity...

University of Malta

Slide 1 of 55

CIS1107/1207 - Design (batch 3)

Design

Moving thoughts and concepts to real-world scenarios

Faculty of ICT

Ernest Cachia Department of Computer

Information Systems

University of Malta

Slide 2 of 55

Contents

• Design principles

• Application of design

• Modular concepts

• Complexity control

Faculty of ICT


Information Systems

University of Malta

Slide 3 of 55

The scope of design

This is simple… moving an abstract description of what a

system is to do, to a how it is to do it in terms of a real-world

environment.

For example:

Analysis might reveal “check status of automatic barrier”;

Design might dictate “communication between computer and

barrier will use a proprietary protocol using four states over

shielded steel cables”


Information Systems Faculty of ICT

University of Malta

Slide 4 of 55

The Nature of Design

• There is no such thing as “bad” design - There are

“different” designs

• There are also designs that do the same thing in different

ways – some more helpful than others

• There are also designs that do not do what was specified –

this is “wrong” (not “bad”) design

Faculty of ICT


Information Systems

University of Malta

Slide 5 of 55

Design Orientation

Conceptual design

– Customer-oriented

What the customer should know about how the

system does what it is meant to do.

Technical design

– Developer-oriented

What the developers understand about how the

system is to do what is specified to do.

Faculty of ICT


Information Systems

University of Malta

Slide 6 of 55

The Fulcrum of Design

Decomposition (aka Breakdown)

– Based (again) on the divide-and-conquer principle

– Can be multi-faceted

– Can depend of system function or data structure

– Can adopt several system viewpoints

– Can be wrongly applied

Faculty of ICT


Information Systems

University of Malta

Slide 7 of 55

The Wasserman Design Approaches

• Modular Decomposition

Relating functions to components

• Data-oriented Decomposition

Relating data elements used by the system

• Event-oriented Decomposition

Relates system states to external events

• Outside-in Design

Black-box approach – care about detail later on

• Object-oriented Design

Relates system function to objects and their interaction

Faculty of ICT


Information Systems

University of Malta

Slide 8 of 55

Messaging

The concept of a “component”

However one tackles design, one must always deal with

“components”. These can be called anything from “module” to

“object”.

User In

terfa

ce

Pro

cess

Managem

ent

Utilitie

s (to

ols

)

Data

In

tegra

tion

Rep

osito

ry

Example: An integrated environment blueprint.

Faculty of ICT


Information Systems

University of Malta

Slide 9 of 55

Another Design Example

A software system structure example:

Top level

Level one

Level two

Faculty of ICT


Information Systems

University of Malta

Slide 10 of 55

Design Failure

Why does the design process sometimes breakdown?*

– Lack of knowledge

No knowledge of design

frameworks/procedures or guidelines

– Cognitive limitations

Failure to consider or include all system aspects

– A bit of both

* According to research done by Guindon, Krasner, and Curtis.

Faculty of ICT


Information Systems

University of Malta

Slide 11 of 55

User Interface Design Issues

• A “slippery fish” by nature!

• However, generally speaking, UI design should be

influenced by aspects such as:

– Human conception issues

– Cultural diversity issues

– User preference issues

– Background and technical expertise issues

– Business/Organisational issues

Faculty of ICT


Information Systems

University of Malta

Slide 12 of 55

Human Conception Issues

Metaphors

– Terms and images used to stimulate and guide human

comprehension

Mental models

– The mental picture formed of the available system functionality and

data organisation

Model navigation rules

– How to navigate the conceived model

Look and feel

– The way a user can obtain information from the system and how

appealing this is for him/her.

Faculty of ICT


Information Systems

University of Malta

Slide 13 of 55

Cultural Diversity Issues

• Language size

• Character representation

• Scripting rules

• Semantic issues

• Religious pre-conceptions

• Social sensitivities

• Gender sensitivity

Faculty of ICT


Information Systems

University of Malta

Slide 14 of 55

User preference Issues

• Also found to be highly influenced by users' cultural

background (Markus 1993)

• Gender plays a decisive role in many preference settings

• Impossible to double-guess

• Impossible to cater for every whim

• Impossible to categorise

• Assumptions are usually wrong in this case (Teasley 1994)

• Should be left as flexible and as user-dependent as

possible

Faculty of ICT


Information Systems

University of Malta

Slide 15 of 55

Background and technical expertise

• Experience with similar systems

• Technical capabilities of the users

• Preconceptions based on lessons learned and

problems encountered

• Bias and expectations

• “Making the connection” or “Extending the known”



University of Malta

Slide 16 of 55

Business/Organisational issues

• Standardisation and profiles

• Logos and “corporate look”

• Perceived efficiency of use

• Customisation

• Generalisation

• Nature of business



University of Malta

Slide 17 of 55

Attributes of a “Good” Design

• Inter-component independence

• Intra-component dependence

• Reduced complexity

• Adequate fault handling (correction?)

Faculty of ICT


Information Systems

University of Malta

Slide 18 of 55

Inter-Component Independence

• This is usually viewed as the degree of coupling between

components.

• COUPLING SHOULD ALWAYS BE MAINTAINED AS

LOW AS POSSIBLE!

• High coupling will always result in the “ripple effect”

Faculty of ICT


Information Systems

University of Malta Levels of Coupling

Context

Common

Control

Stamp

Data

None

High

Low

Loose

Faculty of ICT


Information Systems

University of Malta

Slide 20 of 55

Intra-Component Dependence

• This is usually referred to as the degree of cohesion

within a given component.

• Cohesion should be maintained as high as possible.

• Systems with low cohesion can give rise to high

maintenance costs and elevated system complexity.

Faculty of ICT


Information Systems

University of Malta

Slide 21 of 55

Levels of Cohesion

Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental

High

Low

Faculty of ICT


Information Systems

University of Malta

Slide 22 of 55

Forms of Cohesion (pictorial)

FUNCTION A

Function B Function C

Function D Function E

FUNCTION A

FUNCTION A'

FUNCTION A''

Logic

FUNCTION A

FUNCTION B

FUNCTION C

Time T0

Time T0 + X

Time T0 + 2X

FUNCTION A

FUNCTION B

FUNCTION C

FUNCTION A

FUNCTION B

FUNCTION C

data FUNCTION A

FUNCTION B

FUNCTION C

Coincidental Logical

Temporal Procedural

Communicational Sequential

FUNC. A (Part 1)

FUNC. B (Part 2)

FUNC. C (Part 3)

Functional

Faculty of ICT


Information Systems

University of Malta

Slide 23 of 55

Design Elaboration

• Definitely requires a precise well-defined problem statement

(i.e. a good specification)

• Guidelines and general strategies by which to smoothly

transit from specification representations to design ones

• Will progress through different levels



University of Malta

Slide 24 of 55

Design Solution Evaluation

• Software is by nature prone to intense subjectivity

• Subjective entities are very difficult to quantify of

qualify (criteria might vary)

• Any design solution can only be evaluated with respect

to the specification of the problem being solved

• A good design has definite demonstrable properties



University of Malta

Slide 25 of 55

Summary

• Structured design attempts to impose some form

of discipline on activities that were traditionally

ad hoc (i.e. haphazard)

• The main aspects of structured design: – force the problem to guide the solution

– improving system understandability

– use of system modeling tools

– use of strategies to move from “what” to “how”

– provide criteria by which to evaluate system quality



University of Malta

Slide 26 of 55

The “Designer”

Risks…

• Never heard of him/her (no job title)

• No specific job description

• Can take on different meanings (depending on the

background or interest of who tackles it)

• Is generally considered to be either an analyst or a

programmer



University of Malta

Slide 27 of 55

The way one treats design (1/2)

• Should be associated with experienced

programmers more than with analysts

– Programmers deal in terms of code so they should be in

a better position to apply design to specific parts of the

software system

– Analysts deal in terms of strategies and general

software system layouts so their idea of design is

usually very generic

• Should be approached as objectively as possible



University of Malta

Slide 28 of 55

The way one treats design (2/2)

• Should ALWAYS be taken very seriously

• Should ALWAYS precede coding

• Should NEVER be bound to a specific programming

language

• Should be used to help simplify matters rather than show

how complicated a system is



University of Malta

Slide 29 of 55

Identifying “sick” software

• It’s unreliable (numerous bugs or breaks down often)

• It’s difficult to manage and maintain

• It’s difficult to alter

• It’s not that good an aid to your work efforts and/or

productivity

• It’s difficult to come to terms with



University of Malta

Slide 30 of 55

Main phases in software development

1. Establishing the requirements of the solution and

specifying its features

2. Analysing the solution and specifying its functions

3. Designing the solution and producing a real-world view

4. Implementing the solution (usually using a programming

language and/or a combo of technologies)

5. Testing the solution and confirm its conformance to

original features

6. Maintaining the solution to keep it relevant as long as

possible



University of Malta

Slide 31 of 55

Implications from development

• The more time you invest in thinking about and planning

your software the less time you will spend testing and

maintaining it

• The amount of thought effort spent on coding should be

very minimal

• The earlier (in the development process) an error is

detected the it costs to rectify



University of Malta

Slide 32 of 83

Segmentation of s/w development effort

Specification

10%

Requirements

10%

Designing

15%

Testing

45%

Coding

20%



University of Malta

Slide 33 of 83

Segmentation of s/w development cost

Specification 3%

Requirements 3%

Designing 5%

Testing 15% Coding 7%

Maintenance 67%



University of Malta

Slide 34 of 55

What is “un-maintainable”

• An un-maintainable solution is one that is:

– Difficult to comprehend

– Difficult to assess its requirements impact

– Difficult to test (“fully”)

– Difficult to change any of its aspects

– Difficult to establish which parts need to be changed

– Has confusing (mismatching) documentation



University of Malta

Slide 35 of 55

Basic design elements

Consider such elements as...

• The module • The data • The relationships

Apply (to the above) the basic principles of...

Abstraction

Formality

Divide and conquer

Hierarchical ordering



University of Malta

Slide 36 of 55

The module

• Abstract entity (not necessarily a procedure or

class)

• Completely non-hardware dependent entity

• Self-contained entity

• Fully (formally) defined entity (both functional and

structural)

• Entity to localise system functionality

• Basic “non-decomposable” entity



University of Malta

Slide 37 of 55

Module attributes

• Name or meaningful identification

• Input (required data)

• Output (produced data)

• Function (converting input to output)

• Communication details (interfacing)

• Mechanics (internal actions)

• Internal data (data used solely by module)



University of Malta

Slide 38 of 55

Module example

Module implementation

(aka Module body)

Module interface

…….

The module



University of Malta

Slide 39 of 55

Various module implementations

• In Pascal: Procedure, function, unit

• In C: Function

• In Java: Class (object instantiation upon execution)

• In Modula-2: Module interface and its implementation

• In English: Paragraph, section, chapter

• In drawings: Quadrilateral, circle, specific symbols, etc.

• In Assembly: Routines

• In human thought: Module!



University of Malta

Slide 40 of 55

The Data

• Abstract entity

• Internal or external (to module) entity

• Share-able entity

• Decompose-able entity

• Completely non-hardware dependent entity

• Communicate-able



University of Malta

Slide 41 of 55

Data Attributes

• Name or meaningfull identification

• Type

• Structure

• Nature (control or information-driven)

• Location(s)

• Passage (source-destination)



University of Malta

Slide 42 of 83

Data Examples

Module A Module B destination co-ordinates

completion signal

count, index: integer;

temp_xcoords: array[1..10] of integer;

temp_ycoords: array[1..10] of integer;

complete: boolean;

(a)

(b)

Module X



University of Malta

Slide 43 of 55

Various Data Representations

• In programming languages: Declarations, attributes,

implicit use, explicit naming conventions, etc.

• In natural languages: Facts, principles, subjects,

quantities, values, measures, etc.

• In drawings: Text, directed arcs, specific symbols, etc.

• In human thought: Data!



University of Malta

Slide 44 of 55

The relationships

• Abstract entities

• Completely non-hardware dependent entities

• Qualify-able entities

• Highly structure-dependent entities

• Data-passage related entities

• Basic “non-decomposable” entity



University of Malta

Slide 45 of 55

Relationship properties

• Name or meaningful identification

• Type

– Explicit/Implicit

– Structural/Procedural

– Single/Multiple

• Nature

– Data motivated

– Control motivated



University of Malta

Slide 46 of 55

Relationship Examples

get value

get data validate

data

component

A component

B

system X

(a) Structural, explicit and

single (b) Structural, implicit and

single

transaction

processing

transaction 1

transaction 2

transaction n (c) Structural, explicit

and multiple

do A do B

(d) Procedural, explicit and

single



University of Malta

Slide 47 of 55

Various relationship representations

• In programming languages: Global and non-local

variables, parameter passing, message exchange,

control structure, etc.

• In natural languages: Reasoning sequence, topic

relevance, point-by-point elaboration, presentation of

details, etc.

• In drawings: Directed and un-directed arcs, symbol

locations, specific symbols, etc.

• In human thought: Relationships!



University of Malta

Slide 48 of 55

Fundamental design strategies

• Functional structuring

Describe a system in terms of the functions of its different parts

• Object structuring

Describe a system as a collection of objects of which it is composed

• Data structuring

Describe a system in relation to the data structures it uses

• No structuring

Pretty obvious, I think.



University of Malta

Slide 49 of 83

ABS example - the system

CAR Anti-skid Braking System (ABS)

ABS computer

Electro-hydraulic

brake servo unit

Electro-hydraulic

brake servo unit

Wheel speed sensor

wheel 1 wheel 2

Wheel speed sensor

Hydraulic supply



University of Malta

Slide 50 of 83

ABS functional structuring

wheel sensors

function 1

Measure

wheel speed

function 2

Store

measured

data

function 3

Calculate

wheel accel./

decelerations

function 4

Output

commands to

brake servos

brake servo units



University of Malta

Slide 51 of 83

ABS object structuring

ABS computer

wheel 1 wheel 2 wheel 3

wheel 4 speed signal

actuator command



University of Malta

Slide 52 of 83

ABS object structuring (altered)

ABS computer

wheel 1 wheel 2

wheel 3

wheel 4 speed signal

actuator command

Diagnostic

computer

Display

unit

TP

TP TP



University of Malta

Slide 53 of 83

ABS data structuring

wheel sensor info.

data input

processes

transform

data process

data output

processes

wheel sensor info.

internal data



University of Malta

Slide 54 of 55

Module specification

• Specify its interface

• Specify its function

• Descriptive

• E.g. Natural language

• Instructional

• E.g. Pseudo-code

• Directly implementable

• E.g. Programming language



University of Malta

Slide 55 of 55

Summary

• The notions behind solution design;

• The importance of structure in design;

• Complexity measures;

• Design aspects and examples;

• The notion of the module;

• Structure and properties of modules;

• Design strategies.

Faculty of ICT


Information Systems

NCC Education Pod Cast PowerPoint Presentationstaff.um.edu.mt/ecac1/files/gozo/SEF-3.pdfUniversity...

Documents

Transcript of NCC Education Pod Cast PowerPoint Presentationstaff.um.edu.mt/ecac1/files/gozo/SEF-3.pdfUniversity...