Presentation is loading. Please wait.

Presentation is loading. Please wait.

Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering.

Similar presentations


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

1 Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering

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

3 Software Engineering Programmer’s approach to SD How is this different from eXtreme Programming? Another view: The longer you postpone coding, the sooner you will finish! 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… 3 N. Kokash, Software Engineering

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

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

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

7 Software Engineering 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). 7 N. Kokash, Software Engineering

8 Software Engineering 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 8 N. Kokash, Software Engineering

9 Software Engineering 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 9 N. Kokash, Software Engineering

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

11 Software Engineering 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 11 N. Kokash, Software Engineering

12 Software Engineering 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 12 N. Kokash, Software Engineering

13 Software Engineering 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:  n 1 : number of unique operators  n 2 : number of unique operands  N 1 : total number of operators  N 2 : total number of operands 13 N. Kokash, Software Engineering

14 Software Engineering 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 } Example operator, 1 occurrence operator, 2 occurrences operand, 2 occurrences 14 N. Kokash, Software Engineering

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

16 Software Engineering More complex metrics Intra-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 ) 16 N. Kokash, Software Engineering

17 Software Engineering 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) 17 N. Kokash, Software Engineering

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

19 Software Engineering 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 19 N. Kokash, Software Engineering

20 Software Engineering 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)? 20 N. Kokash, Software Engineering

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

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

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

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

25 Software Engineering 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 25 N. Kokash, Software Engineering

26 Software Engineering 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 26 N. Kokash, Software Engineering

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

28 Software Engineering 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 28 N. Kokash, Software Engineering

29 Software Engineering 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 A B B C C D D sequence B * iteration B o C o D o A A selection A A 29 N. Kokash, Software Engineering

30 Software Engineering JSP Example 30 N. Kokash, Software Engineering

31 Software Engineering JSP Example 31 N. Kokash, Software Engineering

32 Software Engineering The same without JSP 32 N. Kokash, Software Engineering

33 Software Engineering 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. 33 N. Kokash, Software Engineering

34 Software Engineering Program inversion 34 N. Kokash, Software Engineering

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

36 Software Engineering 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 36 N. Kokash, Software Engineering

37 Software Engineering 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 37 N. Kokash, Software Engineering

38 Software Engineering 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 38 N. Kokash, Software Engineering

39 Software Engineering 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” 39 N. Kokash, Software Engineering

40 Software Engineering 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 40 N. Kokash, Software Engineering

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

42 Software Engineering 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 42 N. Kokash, Software Engineering

43 Software Engineering 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 Identify interface and implementation of classes and objects 43 N. Kokash, Software Engineering

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

45 Software Engineering 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. 45 N. Kokash, Software Engineering

46 Software Engineering 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 46 N. Kokash, Software Engineering

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

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

49 Software Engineering 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 49 N. Kokash, Software Engineering

50 Software Engineering 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 50 N. Kokash, Software Engineering

51 Software Engineering 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 51 N. Kokash, Software Engineering

52 Software Engineering 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 52 N. Kokash, Software Engineering

53 Software Engineering 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 53 N. Kokash, Software Engineering

54 Software Engineering 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 54 N. Kokash, Software Engineering

55 Software Engineering 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. Homework 55 N. Kokash, Software Engineering

56 Software Engineering Software Engineering (3 rd 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 56 N. Kokash, Software Engineering


Download ppt "Software Engineering Natallia Kokash 1 N. Kokash, Software Engineering."

Similar presentations


Ads by Google