cs350 lecture 6 software design
TRANSCRIPT
Big Guy’s Thought on Programming
CS350 Software Engineering, SoC, KAIST 22018-04-23
Big Guy’s Thought on Programming
CS350 Software Engineering, SoC, KAIST 32018-04-23
Big Guy’s Thought on Programming
CS350 Software Engineering, SoC, KAIST 42018-04-23
Big Guy’ Thought on Programming
CS350 Software Engineering, SoC, KAIST 52018-04-23
Big Guy’s Thought on Programming
CS350 Software Engineering, SoC, KAIST 62018-04-23
• “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
CS350 Software Engineering, SoC, KAIST 8
“Computer Programming is a Dying Art” (Source: Newsweek, by Kevin Maney, 2014)
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.
CS350 Software Engineering, SoC, KAIST 9
“Computer Programming is a Dying Art” (Source: Newsweek, by Kevin Maney, 2014)
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
β1
β2
β3
λ1
λ2
λ3 Program that satisfies X: f(α1) ◦ g(β2) ◦ h(λ3)
Source Binary
OR
Source Binary
ORX X
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
CS350 Software Engineering, SoC, KAIST 102018-04-23
“ 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?
CS350 Software Engineering, SoC, KAIST 112018-04-23
• 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?
CS350 Software Engineering, SoC, KAIST 12
Art in Programming/Software Engineering
2018-04-23
A Big Guy’s Thought on Programming!
CS350 Software Engineering, SoC, KAIST 132018-04-23
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
CS350 Software Engineering, SoC, KAIST 142018-04-23
• 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.
CS350 Software Engineering, SoC, KAIST 15
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
17CS350 Software Engineering, SoC, KAIST2018-04-23
• 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.
CS350 Software Engineering, SoC, KAIST 18
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
2018-04-23 CS350 Software Engineering, SoC, KAIST 20
• 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)
CS350 Software Engineering, SoC, KAIST 21
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
22CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
23CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
24CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
25CS350 Software Engineering, SoC, KAIST2018-04-23
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
27CS350 Software Engineering, SoC, KAIST2018-04-23
• All the elements in the module are activated at a single time.• Examples:
• Initialization• Termination
Temporal Cohesion
28CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
29CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
30CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
31CS350 Software Engineering, SoC, KAIST2018-04-23
Module with Informational Cohesion
Entry
Exit
Entry
Exit
Entry
Exit
Definition of sales_region_table
initialize_sales_region_table
update_sales_region_table
print_sales_region_table
... ...
... ...
... ...
32CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
33CS350 Software Engineering, SoC, KAIST2018-04-23
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
34CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
35CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
36CS350 Software Engineering, SoC, KAIST2018-04-23
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( );
}
CS350 Software Engineering, SoC, KAIST 372018-04-23
• Drawbacks:• Reduce readability.• Can introduce side effects.• Difficult to maintain.• Difficult to reuse.• May cause security problems.
Common Coupling
38CS350 Software Engineering, SoC, KAIST2018-04-23
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.
39CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
40CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
41CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
42CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
43CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
44CS350 Software Engineering, SoC, KAIST2018-04-23
• Select/Design data representation • Concept of persistency
• Operation(behavior) > Data• Operation = Data• Operation < Data
CS350 Software Engineering, SoC, KAIST 45
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
46CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
47CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
48CS350 Software Engineering, SoC, KAIST2018-04-23
• Data flow-oriented: Structured Design• Object-Oriented• Real-Time• Distributed/Parallel
Software Design Methods
49CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
50CS350 Software Engineering, SoC, KAIST2018-04-23
• Components of Structured chart
Module
Data/control flow
Selection and iteration
Reused modules
Structured Design (Cont.)
51CS350 Software Engineering, SoC, KAIST2018-04-23
• 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.)
52CS350 Software Engineering, SoC, KAIST2018-04-23
• Transform Analysis• Transaction Analysis
From DFD to Structured Chart
53CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
54CS350 Software Engineering, SoC, KAIST2018-04-23
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.
55CS350 Software Engineering, SoC, KAIST2018-04-23
Structured Chart for the ATM Example(Not a good one!)
Main
Read Acct. No. & Sec. code
ValidateAcct. No &Sec. code
RecordTransaction
UpdateAcct.
Debit Acct.
RetrieveAcct.Record
ReadAmount
a,b
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
c
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
57CS350 Software Engineering, SoC, KAIST2018-04-23
Functions
Procedures
Objects
Comparison of functions, procedures and objects.
Function fX f (X)input output
Procedure PX P(X)
Global variables
Pointer variables
input
interface
value
Object State
op1, op2, op3, ...
Message Output
58CS350 Software Engineering, SoC, KAIST2018-04-23
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]
2018-04-23 CS350 Software Engineering, SoC, KAIST 59
What is Next? Service? (From Prof. Inyoung Go)
• Procedures or functions
• Classes or types
• Modules or packages
• DBMS, GUI, applications
• Plug-ins, applets, servlets, Web services
2018-04-23 CS350 Software Engineering, SoC, KAIST 60
[Component-based Software Engineering, Alex Wolf, Univ. of Colorado]
2010s+ SOA
What is Next? Service? (From Prof. Inyoung Go)
2018-04-23 CS350 Software Engineering, SoC, KAIST 61
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
62CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
63CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
64CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
65CS350 Software Engineering, SoC, KAIST2018-04-23
• 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
66CS350 Software Engineering, SoC, KAIST2018-04-23
CS350 Software Engineering, SoC, KAIST 67
Use Case Diagram for the ATM Example
Order Statement
Withdraw Cash
CheckBalance
BankMember
Select Account
«include»
«include»
«include»
CardHolder
Print Balance
«extend»
2018-04-23
CS350 Software Engineering, SoC, KAIST 68
Class Diagram for the ATM Example
CardHolder
Debit Credit
holds 1..3 * Account
Transaction
1*
Simple ATM class diagram, showing static structure for banking domain
2018-04-23
CS350 Software Engineering, SoC, KAIST 69
Sequence Diagram for the ATM Example
select withdrawal menu
withdraw sum add d
ebitdebit account
dispense sum
select amountwithdraw
sum
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
70CS350 Software Engineering, SoC, KAIST2018-04-23
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
71CS350 Software Engineering, SoC, KAIST2018-04-23
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.)
72CS350 Software Engineering, SoC, KAIST2018-04-23
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 Software Engineering, SoC, KAIST 732018-04-23