CS350 Lecture 6 Software Design

CS350 Lecture 5Software Design

Doo-Hwan Bae

SoC, KAIST

bae@se.kaist.ac.kr

Big Guy’s Thought on Programming

CS350 Software Engineering, SoC, KAIST 22018-04-23

Big Guy’ Thought on Programming

• “There is definitely a need for people to learn kind of a computer science way of thinking about problems, but not necessarily the language du jour,” says Erik Brynjolfsson, a professor at the MIT Sloan School of Management

• Irving Wladawsky-Berger, formerly of IBM and now at New York University, “We should definitely teach design. This is not coding, or even programming. It requires the ability to think about the problem, organize the approach, know how to use design tools.”

• But, in 2030, when today’s 10-year-olds are in the job market, they’ll need to be creative, problem-solving design thinkers who can teach a machine how to do things.

• http://www.newsweek.com/2014/06/06/computer-programming-dying-art-252618.html

CS350 Software Engineering, SoC, KAIST 7

“Computer Programming is a Dying Art” (Source: Newsweek, by Kevin Maney, 2014)

2018-04-23

• IBM Research chief John Kelly likes to say we’re at the dawn of an era of brain-inspired cognitive computers—and the beginning of the end of the 60-year reign of programmable computers that required us to tell them what to do step by step.

• The next generation of computers will learn from their interactions with data and people.

• In another decade or so, we won’t program computers—we’ll teach them

2018-04-23

• MUSE(Mining and Understanding Software Enclaves)• http://www.darpa.mil/program/mining-and-understanding-software-enclaves

• The MUSE program is interested in close and continued collaboration of experts from a range of fields, including but not limited to: programming languages, program analysis, theorem proving and verification, testing, compilers, software engineering, machine learning, databases, statisticians, systems and a multitude of application domains. The program intends to emphasize creating and leveraging open source technology.

2018-04-23

A New SW Development Paradigm: MUSE?

Program Analysis, Theorem Proving, Testing

Learning and Synthesis

Property Checkingand Repair

Query: “Synthesize a program that does X”

α1 α2

λ3 Program that satisfies X: f(α1) ◦ g(β2) ◦ h(λ3)

Source Binary

Inspection

Discovery

Graph Database andMining Engine

Analytics

Artifact Generation

Paradigm shift: replace costly and laborious test/debug/validate cycle with “always on” program analysis, mining, inspection, & discovery

“ Let us have a break …”

• What are you doing now?• Learning…

• More important question is, • “What will you do in future?”

• What am I doing?• Teaching…

• What are you doing?

• Is a programming art?• Programming consists of a problem understanding and proposing a source

code to it. • Proposing a source code includes

• Logic/data structure design/selection + coding& debugging• Analysis/design activities are included, but mostly done implicitly.

• Another Q: Is programming an art or science?

• If artistic activity exists in Software Engineering, what activity will be?

• Engineering: Requirements, Design, Coding, Testing, Maintenance, …• Supporting and managing processes

• Can we teach/learn how to be an artist/ a programmer?

Art in Programming/Software Engineering

2018-04-23

A Big Guy’s Thought on Programming!

Teaching/Learning Artistic Activities in SW Development• Drawing a picture vs. Programming/Software Engineering

• Let us discuss Similarity vs. Difference

• What/How to learn to be a good programmer/software engineer?

• Let us discuss

• A process to transform user requirements into some suitable form, which helps the programmer in software coding and implementation.

• For assessing user requirements, an SRS (Software Requirement Specification) document is created whereas for coding and implementation, there is a need of more specific and detailed requirements in software terms. The output of this process can directly be used into implementation in programming languages.

• Software design is the first step in SDLC (Software Design Life Cycle), which moves the concentration from problem domain to solution domain. It tries to specify how to fulfill the requirements mentioned in SRS.

What is SW ‘Design’?

2018-04-23

• The First step to propose a solution for the problem under development

• What is importance of software design?• Design is the place where _____ is fostered.• Design provides us with representations of S/W that can be assessed for _____ .

Why Is Design Important?

16CS350 Software Engineering, SoC, KAIST2018-04-23

• Abstraction• Stepwise refinement: decomposition• Modularity Modularization• Information hiding• Top-down versus Bottom-up

Design Concepts

• Modularization is a technique to divide a software system into multiple discrete and independent modules, which are expected to be capable of carrying out task(s) independently. These modules may work as basic constructs for the entire software.

• Designers tend to design modules such that they can be executed and/or compiled separately and independently.

Modularization (1/3)

Modularization(2/3)

• A complex problem is broken down into several manageblepieces.

• Let P1 and P2 be the two problems• Let E1 and E2 be the effort required to solve P1 & P2, resp.• If C(P1) > C(P2), then E(P1) > E(P2)

• C: Complexity• E: Effort

• If C(P1+P2) > C(P1) + C(P2), then E(P1+P2) > E(P1)+E(P2)• It is easier to solve a complex problem when it is broken into smaller pieces.

2018-04-23 CS350 Software Engineering, SoC, KAIST 19

Modularization (3/3)

• Minimum cost

• Encapsulation means drawing a boundary around something. It means being able to talk about the inside and the outside of it. Object-oriented languages provide a way to do this. Some provide several ways.

• Information hiding is the idea that a design decision should be hidden from the rest of the system to prevent unintended coupling.

• Encapsulation is a programming language feature.• Information hiding is a design principle.

(source: wiki)

Encapsulation vs. Information Hiding

2018-04-23

• A design should exhibit a hierarchical structure.• A design should be modular.• A design should contain distinct and separable representation of data and procedure.

• A design should lead to modules that exhibit independent functional characteristics.

• A design should lead to interfaces that reduce the complexity of connections between modules and with the external environment.

Characteristics of Good Design

• Good design ==> Maintainable• Cohesion: Functional relatedness• Coupling: Strength of interconnectedness• Understandability

• Descriptive names• Structural complexity

• Adaptability• High cohesion, low coupling• Design documentation• Visibility• Self-containment

Software Design Quality

• Functional independence• Based on the concepts of abstraction and information hiding.• Each module has

• a specific functionality of requirements • a simple interface when viewed from outside.

• Measured by two qualitative criteria:• cohesion • coupling

Effective Modular Design

• The measure of strength of the association of elements within a module.

• Modules whose elements are strongly and genuinely related to each other are desired.

• Levels of cohesion• Coincidental• Logical• Temporal• Procedural• Communicational better quality• Informational• Functional

Cohesion

Coincidental Cohesion• The elements in a module are not related but simply bundled together.

• Where does this type of cohesion come from?• Sloppy maintenance• Subroutinization

... Subroutine P

... A;s: A; B;

B; C;C; End P;

... ...

... s: Pt: A; ...

B; ...C; ...

... t: P

... ...

... ...26CS350 Software Engineering, SoC, KAIST2018-04-23

• The elements in a module perform similar or related functions that fall into the same logical class.

• Examples:• InputAll, OutputAll.• General error handling.

Logical Cohesion

• All the elements in the module are activated at a single time.• Examples:

• Initialization• Termination

Temporal Cohesion

• The elements in a module are involved in different activities, but are invoked as a sequence.

• Examples:• Calculate_Trajectory and Activate_Alarms;• Read part_number from DB and Update repair_record on

maintenance_file;

Procedural Cohesion

• All of the elements in a module operates on the same input data or produce the same output data.

• Examples:• Calculate new trajectory and send it to printer;• Update record in DB and write it to audit file;

Communicational Cohesion

• A module performs a number of actions, each with its own entry point, with independent code for each action, all performed on the same data structure.

• Essentially an implementation of an abstract data type.• Example: Class in OO

Informational Cohesion

Module with Informational Cohesion

Definition of sales_region_table

initialize_sales_region_table

update_sales_region_table

print_sales_region_table

... ...

• A module performs exactly one action or achieves a single goal.

• Improve reusability.• Ease to maintain.• Ease to extend.• Examples:

• Get temperature of furnace.• Compute orbital of electron.• Calculate sales commission.

Functional Cohesion

Cohesion Exercise

compute average dailytemperature at various sites

initializesums andopen files

createnew

temperaturerecord

storetemperature

record

close filesand printaverage

temperature

read in site,

time, and temperature

store record

for specific site

edit site, time, ortemperaturefield

• The measure of the interdependence of one module to another.

• Low coupling minimize ripple effect.• Levels of coupling

• Content• Common• Control better quality• Stamp• Data

Coupling

• One module branches into another module. • One module references or alters data contained inside another module.

• Examples:• Module P modifies a statement of module Q.• Module P refers to local data of module Q.• Module P branches to a local label of Module Q

Content Coupling

Common Coupling

• Two modules share the same global variables• Example: ‘common’ in Fortran

WHILE (global_variable == 0){

if(parameter_xyz > 25)function_3( );

elsefunction_4( );

• Drawbacks:• Reduce readability.• Can introduce side effects.• Difficult to maintain.• Difficult to reuse.• May cause security problems.

Common Coupling

Control Coupling• Two modules communicate through control flags.

• One module explicitly controls the logic of the other.

• Q: control-coupled?``Module P calls module Q, and passes back a flag to P that says,

"I am unable to complete my task.", then Q is passing data.''If the flag means, "I am unable to complete my task; accordingly,

write error message ABC123.” control coupled

• Drawbacks:• Two modules are not independent.• Generally associated with logical cohesion.

• Two modules communicate via a passed data structure which contains more information than necessary.

• Example:• Calculate_withholding(employee_record).

• Drawbacks:• Difficult to understand the interface.• Difficult to reuse.

Stamp Coupling

• Two modules communicate via parameters.• Should be a goal of design.• Easy to maintain• Examples:

• Display_time_of_arrival (flight_number).• Compute_product(first_number, second_number, result).

Data Coupling

• Is functional cohesion always good?There might be some occasions in which we have to choose

another type of cohesion instead of functional cohesion. When it will be?

• Is data coupling always good?There might be some occasions in which we have to use

common coupling, I.e. global variables.When it will be?

Questions

• Preliminary design: transformation of requirements into data and software architecture.

• Detailed design: refinements to the architectural representation that lead to detailed data structure and algorithmic representations for software

Design Classification: Management Aspects

• Data design: transformation of the information domain model created during analysis into the data structures.

• Architectural design: definition of the relationship among major structural components of the software.

• Procedural design: transformation of structural components into a procedural description of the software.

• (User) Interface design: establishment of the layout and interaction mechanisms for human-machine interaction.

Design Classification:Technical Aspects

• Select/Design data representation • Concept of persistency

• Operation(behavior) > Data• Operation = Data• Operation < Data

Data (Base) Design

2018-04-23

• Goal:• To develop a modular program structure.• To represent the control relationships between modules.• Also, melds program structure and data structures, defining interfaces.

• A story:You've saved money, purchased a beautiful piece of land, and have decided to build a house of your dreams. Having no experience in such matters, you visited a builder and explain your desire[e.g., size and number of rooms, etc. The builder listens carefully, asks a few questions, and then tells you that he'll have a design in a few weeks. As you wait anxiously for his call, you come up with many different images of your new house. What will he come up with? Finally, the phone rings and you rush to his office. Pulling out a large folder, the builder spreads a diagram of the plumbing for the second floor bathroom in front of you and proceeds to explain it in detail. "But what about the overall design!" you say."Don't worry,'' says the builder,"We will get to that later."'

Architectural Design

• Define algorithmic details.• sequence, control, repetition.

• Notations:• Graphical design notation

Flowcharts,Nassi-Shneiderman charts

• Tabular design notationDecision tables

• Program design languagesStructured English Pseudocode

Procedural Design

• Step 1 Obtain background information• Step 2 Define the semantics of the user interface• Step 3 Define the syntax and format of the interface ( including choices of interaction style)

• Step 4 Choose the physical devices• Step 5 Developing the software• Step 6 Integrate and install the system• Step 7 Provide on-site and product support

User Interface Design

• Data flow-oriented: Structured Design• Object-Oriented• Real-Time• Distributed/Parallel

Software Design Methods

• Used in conjunction with Structured Analysis method.• Design process

Refine data flow diagramWhile not satisfactory do

If type of flow is "transform" thenIdentify incoming/outgoing branches

Map to transform structure else /*is "transaction“, meaning a selection from many options*/

Identify transaction center and data acquisition pathMap to transaction structure

endifFactor the structureRefine the structure using design heuristicsDevelop interface description andglobal data structure.Review

endwhilePerform detailed design

Structured Design

• Components of Structured chart

Module

Data/control flow

Selection and iteration

Reused modules

Structured Design (Cont.)

• Design Heuristics(Guidelines)• Evaluate the first-cut program structure to reduce coupling and improve

cohesion.• Attempt to minimize structures with high fan-out; strive for fan-in as depth

increases.• Keep scope of effect of a module within the scope of control of that

module.• Evaluate module interfaces to reduce complexity and redundancy and

improve consistency.• Define modules whose function is predictable, but avoid modules that are

overly restrictive.• Strive for single-entry-single-exit modules.• Package software based on design constraints and portability requirements.

Structured Design (Cont.)

• Transform Analysis• Transaction Analysis

From DFD to Structured Chart

• Simplified Automatic Teller Machine (ATM) requirements :• ATM receives the customer's ATM card and security code, and

validates the ATM card and security code.• Once they are validated, the account record is received from the

account database, and then ATM asks the customer to enter an amount to be retrieved.

• ATM processes the customer's transaction by debiting account, recording transaction to the transaction database and updating the account.

An SA/SD Example

Data Flow Diagram for the ATM Example

Customer

Get AmountAmount Record

transaction

Get Acct. Number& security code

Retrieve Acct. Record

System DB Acct. DB

Validate Acct. No. &Sec. Code

Debit Acct.

Acct.Record

NewAcct.Info.

Acct. No.

Acct. No.Sec. code

Update Acct.

RecordDB

trans.

Structured Chart for the ATM Example(Not a good one!)

Read Acct. No. & Sec. code

ValidateAcct. No &Sec. code

RecordTransaction

UpdateAcct.

Debit Acct.

RetrieveAcct.Record

ReadAmount

a,b da e

d,e f f g

•a : Account number b : Security number•c : Validation number d : Amount •e : Account record f : New Account info.•g : Transaction Info. 56CS350 Software Engineering, SoC, KAIST

2018-04-23

• Creates a representation of the real-world problem domain and maps it into a solution in such a way that the design interconnects data items and processing operations so that information and processing can be modularized together.

• A design method that supports the following principles efficiently:

• Decomposability• Composability• Understandability• Continuity• Protection

Object-Oriented Design

Functions

Procedures

Objects

Comparison of functions, procedures and objects.

Function fX f (X)input output

Procedure PX P(X)

Global variables

Pointer variables

interface

Object State

op1, op2, op3, ...

Message Output

What is Next? Service? (From Prof. Inyoung Go)

• Service (economics)• “An intangible commodity” [Wikipedia]

• “Economic activities offered by one party to another” [FFS+11]

• “Services are an example of intangible economic goods”

• Service (systems architecture)• “A set of related software functionalities that can be reused for

different purposes, together with the policies that should control its usage” [Wikipedia]

• IT service (e-service): a service offered or deployed using IT infrastructure [FFS+11]

• Service-oriented architecture (SOA)• A software design and software architecture design pattern based on

structured collections of discrete software modules, known as services [Wikipedia]

• Procedures or functions

• Classes or types

• Modules or packages

• DBMS, GUI, applications

• Plug-ins, applets, servlets, Web services

[Component-based Software Engineering, Alex Wolf, Univ. of Colorado]

2010s+ SOA

Service Interface Service InterfaceServiceInterface

Services

End Users

Client Software

Service Mashup/Composition Service Mashup/Composition

Component Interface Component InterfaceComponentInterface

Components and Modules

Heterogeneous Platforms

• Identity: Each object is a discrete, distinguishable entity. • e.g. "paragraphs" in a document, • "sensors" in processor monitoring system, • "queens" in a chess program, • "lines" and "rectangles" in CAD user interface.

• Classification: Objects with the same data structure and operations are grouped into a class. Each object is an instance of a class.

• Message sending: Objects communicate through the interface via message passing

Characteristics of Objects

• Classes• A class is a specification for an arbitrary number of similar objects (a template for

objects).• It allows to build a taxonomy of objects on an abstract, conceptual level.

• Instances• Every object is an instance of some class.• There can be many instances of the same class, and the objects created from the

same class have the same behavior, but each of such objects is unique.

Classes and Instances

• The ability of more than one object responding to the same message in its own way.

• The same operation (method) can behave differently on different classes.

• It is allowed by limiting object access to a strictly defined interface.

• Types of Polymorphism• Coercion, Overloading, Subtyping, Parametric polymorphism

Polymorphism

• The ability of one class to define the behavior and data structure of its instances as a superset of the definition of another class or classes.

• It provides a mechanism for classification.• It allows to abstract the similarities between classes, and to specify only the differences for the new class.

• Subclass: A class that inherits behavior from another class.• It usually adds its own behavior to define its own unique kind of object.

• Superclass: a class from which specific behavior is inherited.

Inheritance

• Identify objects and their attributes.• Identify operations applied to objects.• Establish interfaces by showing the relationship between objects and operations.

• Decide on detailed design issues that will provide an implementation description for objects.

• Recursively apply those steps above.

Object-Oriented Approach

Use Case Diagram for the ATM Example

Order Statement

Withdraw Cash

CheckBalance

BankMember

Select Account

«include»

CardHolder

Print Balance

«extend»

2018-04-23

Class Diagram for the ATM Example

CardHolder

Debit Credit

holds 1..3 * Account

Transaction

Simple ATM class diagram, showing static structure for banking domain

2018-04-23

Sequence Diagram for the ATM Example

select withdrawal menu

withdraw sum add d

ebitdebit account

dispense sum

select amountwithdraw

return card

:ATMUI :CashDispenser:ATMControl :CardHolder :Account

:Debit

2018-04-23

• Common OO approach steps• step1. Identify objects(attributes and methods)• step2. Determine the relationships among objects• step3. Design & implement objects

• Functional approach steps• step1. Identify functionality• step2. Determine the relationships among functions• step3. Design and implement functions

Object-Oriented vs. Functional

In General, • Abstraction mechanisms enhance

• comprehensibility,• reusability,• maintainability, • modifiability and • extensilibity.

• Smooth transition from the analysis phase to design and implementation is possible -- unifying paradigm.

Benefits of Object-Oriented Approach

In OOD,• All shared data areas are eliminated.

• Reduce coupling

• Objects are independent entities.• No access hence no deliberate or accidental use of the internal information of the

object by another object is possible.• An object can be modified without reference to other objects.

• Objects may be distributed and may execute in parallel.• Logically distributed, autonomous entity.

Benefits of Object-Oriented Approach (Cont.)

Summary

• OO approach supports SE principles better than old approaches

• Design is a place where SW quality is fostered• Design experiences can be reused through design patterns• Service-Oriented SE tries to enhance software development efficiency and cost-effectiveness by reusing large-granularity artifacts through standardization.

• What is next? MUSE!?

CS350 Lecture 6 Software Design

Documents

CS350: Data Structures Queues - GitHub Pagesycpcs.github.io/cs350-fall2014/lectures/Queues_lecture.pdf · CS350: Data Structures Queue Implementation Using an Array 21! /** * Return

Lecture 2.6 software

Software Engineering Lecture 7 Lecture # 7

CS350 CD3412 User Manual

CS350: Data Structures Hash Tables - GitHub Pagesycpcs.github.io/cs350-fall2014/lectures/Hash_Tables.pdf · CS350: Data Structures Hash Function • Hash function maps keys of a given

Models Object-Oriented Software Engineering CS350

CS 350 Algorithms and Complexity - Computer Action Teamweb.cecs.pdx.edu/~black/cs350/Lectures/lec04-rec ana… · · 2015-10-08CS 350 Algorithms and Complexity Fall 2015 Lecture

CS350 Lecture 3 Requirements Engineeringse.kaist.ac.kr/wp-content/uploads/2019/03/CS350-Lecture-2-RE.pdfin SW Development Projects Some advices from industry practitioners ... diagram

2017-Spring CS350 Project #02 Review - SE LAB | KAISTse.kaist.ac.kr/wp-content/uploads/2017/02/CS350... · 2017-Spring CS350 Project #02: Software Requirements Specification (SRS)

CS350 CH06 Non Binary Trees

CS350: Operating Systems

Topics in Distributed Systems CS350, CS552, CS580F

Lecture 1 - Software and Software Engineering

Case Storage CS350 - silverstonetek.com · with optional tool-less rail slide*. With an overall package designed for maximizing efficiency, flexibility, and durability, the CS350

CS350 Operating Systemsali/cs350-f19/synch.pdfReview: Processes Aprocessisaninstanceofarunningprogram-Athreadisanexecutioncontext-Processcanhaveoneormorethreads-Threadsshareaddressspace(code,data,heap),openfiles

Chapter 14Chapter 14 Testing Tactics - KAISTswtv.kaist.ac.kr/courses/cs350-08/ch14_part1.pdf · Overview of Ch14. Testing TacticsOverview of Ch14. Testing Tactics 14.1 Software Testing

CS350: Data Structures Red-Black Trees - GitHub …ycpcs.github.io/cs350-fall2014/lectures/Red-Black_Trees.pdfCS350: Data Structures Red-Black Tree (Cont.) • A red-black tree is

E – Virtual Memory Virtual Memorycs350/F06/slides/cs350... · 2006. 10. 10. · CS350 – Operating Systems University of Waterloo, Fall 2006 Stefan Buettcher

CS 350 Lecture 5-3 Resilient Design - KAISTse.kaist.ac.kr/wp-content/uploads/2019/11/CS350-Lecture... · 2019-11-24 · •Distributed systems are every corner of our society •Attempts

Creational Patterns (1) CS350, SE310, Fall, 2010