Your SlideShare is downloading. ×
0
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Week 6
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Week 6

69

Published on

for software engineering

for software engineering

Published in: Engineering, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
69
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Software Engineering Software Design Slide 1 Software Engineering Software Design
  • 2. Software Engineering Software Design Slide 2 Software Design Deriving a solution which satisfies software requirements
  • 3. Software Engineering Software Design Slide 3 Stages of Design • Problem understanding – Look at the problem from different angles to discover the design requirements. • Identify one or more solutions – Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources. • Describe solution abstractions – Use graphical, formal or other descriptive notations to describe the components of the design. • Repeat process for each identified abstraction until the design is expressed in primitive terms.
  • 4. Software Engineering Software Design Slide 4 The Design Process • Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships. • The system should be described at several different levels of abstraction. • Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.
  • 5. Software Engineering Software Design Slide 5 Phases in the Design Process Architectural design Abstract specificatio n Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Requirements specification Design activities Design products
  • 6. Software Engineering Software Design Slide 6 Design Phases • Architectural design: Identify sub-systems. • Abstract specification: Specify sub-systems. • Interface design: Describe sub-system interfaces. • Component design: Decompose sub-systems into components. • Data structure design: Design data structures to hold problem data. • Algorithm design: Design algorithms for problem functions.
  • 7. Software Engineering Software Design Slide 7 Design • Computer systems are not monolithic: they are usually composed of multiple, interacting modules. • Modularity has long been seen as a key to cheap, high quality software. • The goal of system design is to decode: – What the modules are; – What the modules should be; – How the modules interact with one-another
  • 8. Software Engineering Software Design Slide 8 Modular programming • In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines” • But modularity cannot bring benefits unless the modules are – autonomous, – coherent and – robust
  • 9. Software Engineering Software Design Slide 9 Procedural Abstraction • The most obvious design methods involve functional decomposition. • This leads to programs in which procedures represent distinct logical functions in a program. • Examples of such functions: – “Display menu” – “Get user option” • This is called procedural abstraction
  • 10. Software Engineering Software Design Slide 10 Programs as Functions • Another view is programs as functions: input output x → f → f (x) the program is viewed as a function from a set I of legal inputs to a set O of outputs. • There are programming languages (ML, Miranda, LISP) that directly support this view of programming
  • 11. Software Engineering Software Design Slide 11 Object-oriented design – The system is viewed as a collection of interacting objects. – The system state is decentralized and each object manages its own state. – Objects may be instances of an object class and communicate by exchanging methods.
  • 12. Software Engineering Software Design Slide 12 Five Criteria for Design Methods • We can identify five criteria to help evaluate modular design methods: – Modular decomposability; – Modular composability; – Modular understandability; – Modular continuity; – Modular protection.
  • 13. Software Engineering Software Design Slide 13 Modular Decomposability • This criterion is met by a design method if the method supports the decomposition of a problem into smaller sub-problems, which can be solved independently. • In general method will be repetitive: sub- problems will be divided still further • Top-down design methods fulfil this criterion; stepwise refinement is an example of such method
  • 14. Software Engineering Software Design Slide 14 Hierarchical Design Structure System level Sub-system level
  • 15. Software Engineering Software Design Slide 15 Top-down Design • In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level. • In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
  • 16. Software Engineering Software Design Slide 16 Modular Composability • A method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems. • Composability is directly related to the issue of reusability • Note that composability is often at odds with decomposability; top-down design, – for example, tends to produce modules that may not be composed in the way desired • This is because top-down design leads to modules which fulfil a specific function, rather than a general one
  • 17. Software Engineering Software Design Slide 17 Examples • The Numerical Algorithm Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc. • The Unix shell provides a facility called a pipe, written “−”, whereby – the standard output of one program may be redirected to the standard input of another; this convention favours composability.
  • 18. Software Engineering Software Design Slide 18 Modular Understandability • A design method satisfies this criterion if it encourages the development of modules which are easily understandable. • EXAMPLE. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method.
  • 19. Software Engineering Software Design Slide 19 Understandability • Related to several component characteristics – Can the component be understood on its own? – Are meaningful names used? – Is the design well-documented? – Are complex algorithms used? • Informally, high complexity means many relationships between different parts of the design.
  • 20. Software Engineering Software Design Slide 20 Modular Continuity • A method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules. • EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used
  • 21. Software Engineering Software Design Slide 21 Modular Protection • A method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules • EXAMPLE. Validating input at source prevents errors from propagating throughout the program.
  • 22. Software Engineering Software Design Slide 22 Five principles for Good Design • From the discussion above, we can distil five principles that should be adhered to: – Linguistic modular units; – Few interfaces; – Small interfaces – Explicit interfaces; – Information hiding.
  • 23. Software Engineering Software Design Slide 23 Linguistic Modular Units • A programming language (or design language) should support the principle of linguistic modular units: – Modules must correspond to linguistic units in the language used • EXAMPLE. Java methods and classes
  • 24. Software Engineering Software Design Slide 24 Few Interfaces • This principle states that the overall number of communication channels between modules should be as small as possible: – Every module should communicate with as few others as possible. • So, in the system with n modules, there may be a minimum of n-1 and a maximum of links; your system should stay closer to the minimum 2 )1( −nn
  • 25. Software Engineering Software Design Slide 25 Few Interfaces
  • 26. Software Engineering Software Design Slide 26 Small Interfaces (Loose Coupling) • This principle states: – If any two modules communicate, they should exchange as little information as possible. • COUNTER EXAMPLE. Declaring all instance variables as public!
  • 27. Software Engineering Software Design Slide 27 • A measure of the strength of the inter-connections between system components. • Loose coupling means component changes are unlikely to affect other components. – Shared variables or control information exchange lead to tight coupling. – Loose coupling can be achieved by state decentralization (as in objects) and component communication via parameters or message passing. Coupling
  • 28. Software Engineering Software Design Slide 28 Tight Coupling Module A Module B Module C Module D Shared data area
  • 29. Software Engineering Software Design Slide 29 Loose Coupling Module A A’s data Module B B’s data Module D D’s data Module C C’s data
  • 30. Software Engineering Software Design Slide 30 • Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing. • However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Coupling and Inheritance
  • 31. Software Engineering Software Design Slide 31 Reusability • A major obstacle to the production of cheap quality software is the intractability of the reusability issue. • Why isn’t writing software more like producing hardware? Why do we start from scratch every time, coding similar problems time after time after time? • Obstacles: – Economic; – Organizational;
  • 32. Software Engineering Software Design Slide 32 Stepwise Refinement • The simplest realistic design method, widely used in practice. • Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods. • Basic idea is: – Start with a high-level spec of what a method is to achieve; – Break this down into a small number of problems (usually no more than 10) – For each of these problems do the same; – Repeat until the sub-problems may be solved immediately.
  • 33. Software Engineering Software Design Slide 33 Explicit Interfaces • If two modules must communicate, they must do it so that we can see it: – If modules A and B communicate, this must be obvious from the text of A or B or both. • Why? If we change a module, we need to see what other modules may be affected by these changes.
  • 34. Software Engineering Software Design Slide 34 Information Hiding • This principle states: – All information about a module, (and particularly how the module does what it does) should be private to the module unless it is specifically declared otherwise. • Thus each module should have some interface, which is how the world sees it anything beyond that interface should be hidden. • The default Java rule: – Make everything private
  • 35. Software Engineering Software Design Slide 35 Cohesion A measure of how well a component “fits together”. • A component should implement a single logical entity or function. • Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component. • Various levels of cohesion have been identified.

×