Presentation is loading. Please wait.

Presentation is loading. Please wait.

N. Kokash, Software Engineering

Similar presentations

Presentation on theme: "N. Kokash, Software Engineering"— Presentation transcript:

1 N. Kokash, Software Engineering
Natallia Kokash Note that the book is misleadingly simple. Just reading the book is like learning to swim without getting wet. N. Kokash, Software Engineering

2 Agenda Software Architecture Software Design Definition
Architecture Design Viewpoints and view models Architectural styles Architecture assessment Software Design Principles Methods N. Kokash, Software Engineering

3 Programmer’s approach to SD
Skip RE and design Start writing code Design is a waste of time We need to show something to the customer We are judged by the amount of LOC/month We know that the schedule is too tight… How is this different from eXtreme Programming? Another view: The longer you postpone coding, the sooner you will finish! N. Kokash, Software Engineering

4 Design principles Abstraction Modularity, coupling and cohesion
Information hiding Limited complexity Hierarchical structure N. Kokash, Software Engineering

5 Abstraction Procedural abstraction: Data abstraction:
Natural consequence of stepwise refinement: name of procedure denotes sequence of actions Data abstraction: Aimed at finding a hierarchy in the data N. Kokash, Software Engineering

6 Coupling and cohesion Cohesion: the glue that keeps a module together
Structural criteria which tell us something about individual modules and their interconnections Cohesion: the glue that keeps a module together Coupling: the strength of the connection between modules N. Kokash, Software Engineering

7 Cohesion types Coincidental (worst): arbitrarily parts (e.g., utiility classes) Logical: parts of a module logically are categorized to do the same thing. Temporal: parts of a module are processed together (e.g., after catching an exception). Procedural: parts of a module always follow a certain sequence of execution (e.g. check file permission). Communicational: parts of a module operate on the same data. Sequential: the output from one part is the input to another part. Functional (best): parts of a module contribute to a single well-defined task (e.g. tokenizing a string of XML). N. Kokash, Software Engineering

8 How to determine the cohesion type?
Describe the purpose of the module in one sentence If the sentence is compound, contains a comma or more than one verb  it probably has more than one function: logical or communicational cohesion If the verb is not followed by a specific object  probably logical cohesion (example: edit all data) If the sentence contains time-related words like “first”, “then”, “after”  temporal cohesion Words like “startup”, “initialize” imply temporal cohesion N. Kokash, Software Engineering

9 Coupling types Content: a module depends on the internal working of another module Common: two modules share the same global data External: modules share an externally imposed data format, or communication protocol Control: one module controls the flow of another, by passing it information on what to do Stamp: modules share a composite data structure and use only part of it Data: modules share data through, e.g., through parameters. Message: Component communicate via message passing N. Kokash, Software Engineering

10 Strong cohesion + weak coupling
Simple interface Simpler communication Simpler correctness proofs Changes influence other modules less often Reusability increases Comprehensibility improves N. Kokash, Software Engineering

11 Information hiding Each module has a secret
Design involves a series of decision For each such decision, wonder who needs to know and who can be kept in the dark Information hiding is related to: Abstraction: if you hide something, the user may abstract from that fact Coupling: the secret decreases coupling between a module and its environment Cohesion: the secret is what binds the parts of the module together N. Kokash, Software Engineering

12 Complexity Measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …) Use these numbers as a criterion to assess a design, or to guide the design Higher value  higher complexity  more effort required (= worse design) Two kinds: intra-modular: inside one module inter-modular: between modules N. Kokash, Software Engineering

13 Size-based complexity measures
Counting lines of code Differences in verbosity Differences between programming languages a:= b versus while p^ <> nil do p:= p^ Halstead’s “software science”, essentially counting operators and operands: n1: number of unique operators n2: number of unique operands N1: total number of operators N2: total number of operands N. Kokash, Software Engineering

14 Example public static void sort(int x []) {
for (int i=0; i < x.length-1; i++) { for (int j=i+1; j < x.length; j++) { if (x[i] > x[j]) { int save=x[i]; x[i]=x[j]; x[j]=save } operator, 1 occurrence operand, 2 occurrences operand, 2 occurrences operator, 2 occurrences N. Kokash, Software Engineering

15 Other computer science formulas
Size of vocabulary: n = n1 + n2 Program length: N = N1 + N2 Volume: V = N log2n Level of abstraction: L = V*/ V Approximation: L’ = (2/n1)(n2/N2) Programming effort: E = V/L Estimated programming time: T ’ = E/18 Estimate of N: N ’ = n1log2n2 : n2log2n2 For this example: N = 68, N ’ = 89, L = .015, L’ = .028 N. Kokash, Software Engineering

16 More complex metrics Intra-modular: Inter-modular:
Structure-based (e.g., McCabe’s cyclomatic complexity: number of edges - number of nodes + number of connected components + 1) Inter-modular: Based on “uses” relation (call graph) Tree impurity (for a graph with n nodes and e edges: m(G) = 2(e-n+1)/(n-1)(n-2) Information flow metric (e.g., Shepperd’s variant ) N. Kokash, Software Engineering

17 Object-oriented metrics
WMC: Weighted Methods per Class DIT: Depth of Inheritance Tree NOC: Number Of Children CBO: Coupling Between Object Classes RFC: Response For a Class LCOM: Lack of COhesion of a Method More in the lectures on software quality (lecture 5) and cost estimation (lecture 11) N. Kokash, Software Engineering

18 Design methods Functional decomposition Data flow design (SA/SD)
Design based on data structures (JSD/JSP) Object-oriented design N. Kokash, Software Engineering

19 Functional decomposition
Extremes: bottom-up and top-down Not used as such; design is not purely rational: clients do not know what they want changes influence earlier decisions people make errors projects do not start from scratch Rather, design has a yo-yo character We can only fake a rational design process N. Kokash, Software Engineering

20 Data flow design Yourdon and Constantine (early 70s)
Nowadays version: two-step process: Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts Do you remember Data Flow Diagrams (DFDs)? N. Kokash, Software Engineering

21 Data flow design Top-level DFD: context view First-level decomposition
Second-level decomposition direction library system request management client report ack’ment N. Kokash, Software Engineering

22 First-level decomposition
Borrow title Prelim doc client catalog adm. management log file request log data return borrow acknowledgement report direction N. Kokash, Software Engineering

23 Second-level decomposition
Check client data log file log data Process request data base return borrow not OK OK client info N. Kokash, Software Engineering

24 Example minispec Identification: Process request Description:
Enter type of request 1.1 If invalid, issue warning and repeat step 1 1.2 If step 1 repeated 5 times, terminate transaction Enter book identification 2.1 If invalid, issue warning and repeat step 2 2.2 If step 2 repeated 5 times, terminate transaction Log client identification, request type and book identification ... N. Kokash, Software Engineering

25 Data dictionary entries
borrow-request = client-id + book-id return-request = client-id + book-id log-data = client-id + [borrow | return] + book-id book-id = author-name + title + (isbn) + [proc | series | other] Conventions: [ ] - include one of the enclosed options | - separates options + - AND () - enclosed items are optional N. Kokash, Software Engineering

26 From data flow diagrams to structure charts
Result of SA: logical model, consisting f a set of DFD’s, augmented by minispecs and data dictionary Structured Design = transition from DFD’s to structure charts Heuristics for this transition are based on notions of coupling and cohesion Major heuristic concerns choice for top-level structure chart, most often: transform-centered N. Kokash, Software Engineering

27 Transform-centered design
B D E F G C H K Do job A C B G F E D K H N. Kokash, Software Engineering

28 Design based on data structures
Jackson Structured Programming (JSP) for programming-in-the-small Jackson Structured Design (JSD) for programming-in-the-large Michael Anthony Jackson (born 1936) is a British computer scientist N. Kokash, Software Engineering

29 JSP Basic idea: good program reflects structure of its input and output Program can be derived almost mechanically from a description of the input and output Input and output are depicted in a structure diagram and/or in structured text/schematic logic (pseudocode) A B C D sequence B * iteration B o C o D o A selection A N. Kokash, Software Engineering

30 JSP Example N. Kokash, Software Engineering

31 JSP Example N. Kokash, Software Engineering

32 The same without JSP N. Kokash, Software Engineering

33 Fundamental issues in JSP
Model input and output using structure diagrams Merge diagrams to create program structure Meanwhile, resolve structure clashes Clash = there is no obvious correspondence between the input and output structures Optimize results through program inversion Design simple programs using JSP and then invert one (or more) programs to optimize the design. N. Kokash, Software Engineering

34 Program inversion N. Kokash, Software Engineering

35 Differences between JSP and other methods
Functional decomposition, data flow design: Problem structure  functional structure  program structure JSP: Problem structure  data structure  program structure N. Kokash, Software Engineering

36 Jackson Structured Design (JSD)
Problem with JSP: how to obtain a mapping from the problem structure to the data structure? JSD tries to fill this gap JSD has three stages: modeling stage: description of real world problem in terms of entities and actions network stage: model system as a network of communicating processes implementation stage: transform network into a sequential design N. Kokash, Software Engineering

37 JSD modeling stage JSD models the UoD as a set of entities
For each entity, a process is created which models the life cycle of that entity This life cycle is depicted as a process structure diagram (PSD) PSD’s are finite state diagrams: the roles of nodes and edges has been reversed the nodes denote transitions while the edges denote states N. Kokash, Software Engineering

38 Object-oriented design principles
Three major steps: Identify the objects Determine their attributes and services Determine the relationships between objects OO as middle-out design First set of objects becomes middle level To implement these, lower-level objects are required A control/workflow set of objects constitutes the top level N. Kokash, Software Engineering

39 Carefully consider candidate list
Eliminate implementation constructs, such as “software” Replace or eliminate vague terms: “system”  “computer” Equate synonymous terms: “customer” and “client”  “client” Eliminate operation names, if possible (such as “transaction”) Be careful in what you really mean Can a client be a library employee? Is it “book copy” rather than “book”? Eliminate individual objects (as opposed to classes) “book’s code”  attribute of “book copy” N. Kokash, Software Engineering

40 Identify relationships
From the problem statement: employee operates station station has bar code reader bar code reader reads book copy bar code reader reads identification card Tacit knowledge: library owns computer library owns stations computer communicates with station library employs employee client is member of library client has identification card N. Kokash, Software Engineering

41 Result: Initial class diagram
N. Kokash, Software Engineering

42 Object-oriented design methods
Booch: early, new and rich set of notations Fusion: more emphasis on process RUP: full life cycle model associated with UML N. Kokash, Software Engineering

43 Booch’ method Identify classes and objects
Identify semantics of classes and objects Identify relationships between classes and objects Identify interface and implementation of classes and objects N. Kokash, Software Engineering

44 Fusion Analysis object model interface model Design object interaction
graphs visibility graphs class descriptions inheritance graphs N. Kokash, Software Engineering

45 RUP Four phases: inception, elaboration, construction, transition
Analysis and design workflow: First iteration: architecture Next, analyze behavior: from use cases to set of design elements produces black-box model of the solution Finally, design components: refine elements into classes, interfaces, etc. N. Kokash, Software Engineering

46 Classification of design methods
Orientation dimension: Problem-oriented: understand problem and its solution Product-oriented: correct transformation from specification to implementation Product/model dimension: Conceptual: descriptive models Formal: prescriptive models Problem-oriented techniques focus on getting a better understanding of problems and solutions. They are human-centered They describe, communicate, document solutions. Product-centered approaches focus n correct transformation. Conceptual models describe an external reality, the UoD. They are checked through validation. Formal models describe the behavior of the system to be developed. They are verified. N. Kokash, Software Engineering © SE, Design, Hans van Vliet

47 Classification of design methods
problem-oriented product-oriented Understand the problem Transform to implementation I ER modeling Structured analysis II Structured design conceptual III JSD VDM IV Functional decomposition JSP formal Represent properties Create implementation units N. Kokash, Software Engineering

48 Caveats when choosing a particular design method
Familiarity with the problem domain Designer’s experience Available tools Development philosophy N. Kokash, Software Engineering

49 Design pattern Provides solution to a recurring problem
Balances set of opposing forces Documents well-prove design experience Abstraction above the level of a single component Provides common vocabulary and understanding Are a means of documentation Supports construction of software with defined properties N. Kokash, Software Engineering

50 Example design pattern: Proxy
Context: Client needs services from other component, direct access may not be the best approach Problem: We do not want hard-code access Solution: Communication via a representative, the Proxy N. Kokash, Software Engineering

51 Example design pattern: Command Processor
Context: User interface that must be flexible or provides functionality beyond handling of user functions Problem: Well-structured solution for mapping interface to internal functionality. All ‘extras’ are separate from the interface Solution: A separate component, the Command Processor, takes care of all commands Actual execution of the command is delegated N. Kokash, Software Engineering

52 Anti-patterns Patterns describe desirable behavior
Anti-patterns describe situations one had better avoid In agile approaches (XP), refactoring is applied whenever an anti-pattern has been introduced N. Kokash, Software Engineering

53 Example antipatterns God class: class that holds most responsibilities
Lava flow: dead code Poltergeist: class with few responsibilities and a short life Golden Hammer: solution that does not fit the problem Stovepipe: (almost) identical solutions at different places Swiss Army Knife: excessively complex class interface N. Kokash, Software Engineering

54 SUMMARY Essence of the design process: decompose system into parts
Desirable properties of a decomposition: coupling/cohesion, information hiding, (layers of) abstraction There have been many attempts to express these properties in numbers Design methods: functional decomposition, data flow design, data structure design, object-oriented design N. Kokash, Software Engineering

55 Homework Read chapter 12 Design the Image2UML system
Use a UML design tool and deliver your design sufficiently documented in a PDF file. The document to be delivered should at least consist of a class diagram, a sequence diagram, an activity diagram and a state chart diagram. N. Kokash, Software Engineering

56 Software Engineering (3rd Ed.)
1. Introduction 2. Introduction to Software Engineering Management 3. The Software Life Cycle Revisited 4. Configuration Management 5. People Management and Team Organization 6. On Managing Software Quality 7. Cost Estimation 8. Project Planning and Control 9. Requirements Engineering 10. Modeling 11. Software Architecture 12. Software Design 13. Software Testing 14. Software Maintenance 17. Software Reusability 18. Component-Based Software Engineering 19. Service Orientation 20. Global Software Development N. Kokash, Software Engineering

Download ppt "N. Kokash, Software Engineering"

Similar presentations

Ads by Google