Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
CS 575:  Software Design Introduction
Software Design Structural Packaging Behavioral Infrastructure Requirements, Test/Validation Criteria A software design is...
Expressing A Software Design <ul><li>Similar to an architects blueprint </li></ul><ul><li>A model is an abstraction of the...
Modeling as a Design Technique <ul><li>Designs are too complicated to develop from scratch </li></ul><ul><li>Good designs ...
Modeling as a Design Technique Models Lets Build this System… Incremental Refinement Design Lets Start Building  this Syst...
Modeling as a Design Technique - Improved Models Lets Build this System… Incremental Refinement Design Lets Start Building...
Modeling Designs… Designing With Models Design Very Complicated To Understand Modeling Tool Model Repository Visualization
UML – A modeling Notation for Design Structural Packaging/Implementation Behavioral Infrastructure/ Environment Requiremen...
Software Architecture <ul><li>According to Shaw and Garlan… The Software Architecture of a system consists of a descriptio...
The Software Architecture “Stack”  Software Architecture Subsystem Decomposition Subsystem Dependencies Subsystem Interfac...
The Software Architecture “Stack”  Software Architecture Subsystem Decomposition Subsystem Dependencies Subsystem Interfac...
Why do we design… <ul><li>Manage complexity </li></ul><ul><li>Validation of delivered software </li></ul><ul><li>Simplify ...
Why is design so hard… <ul><li>Software design can’t be taught, but principles of good design can </li></ul><ul><li>There ...
How Humans Design... From “Wicked Problems and Social Complexity”  http://www.cognexus.org/id42.htm , Jeff Conklin
Software Design (for non-trivial applications) is a “Wicked Problem” <ul><li>“ You don't understand the problem until you ...
Software Design (for non-trivial applications) is a “Wicked Problem” <ul><li>“ Every wicked problem is unique and novel” <...
Why what you learned in software engineering 101 does not work... <ul><li>From Raymonde Guindon's paper “Designing the Des...
Design Methodologies Extreme Programming Waterfall Iterative
Software Development Methodology <ul><li>A Methodology is: </li></ul><ul><ul><li>A Process </li></ul></ul><ul><ul><ul><li>...
Modeling Emphasis for Different Design Approaches Component Oriented Traditional/ Structured Object Oriented Data Structur...
Jumpstarting Design Starting from scratch “blank screen” is tough.  Components of a design toolbox – Templates,  Patterns,...
Example:  Jakarta Struts Presentation Framework
Example:  J2EE  Architecture Patterns Source: http://java.sun.com/ blueprints/ corej2eepatterns/Patterns/
Example:  Intercepting Filter Pattern Architectural Pattern <ul><li>Problem:  Preprocessing and post-processing of a clien...
Design Patterns <ul><li>Example:  Observer Pattern </li></ul><ul><ul><li>Define a one-to-many dependency between objects s...
What’s good about Patterns <ul><li>They solve common problems in a “proven” way </li></ul><ul><li>They tend not to be impl...
Design Quality <ul><li>Software design “quality”, as with other ideas on quality, is an elusive concept: </li></ul><ul><li...
How to “Fix” A Software Design <ul><li>Many times the source code is the only up-to-date documentation for a software syst...
Improving Existing Designs - Refactoring <ul><li>See Martin Fowler’s Book </li></ul><ul><li>What is Refactoring: </li></ul...
Example:  Refactoring – PushDown Method Bill +setName() +getAddress() … +send() Bill +setName() +getAddress() … #send() EB...
Anti-Patterns (plus Refactoring) <ul><li>AntiPatterns are Negative Solutions that present more problems than they address ...
Antipattern Example: Poltergeists  <ul><li>Proliferation of classes [Riel 96]  </li></ul><ul><li>Spurious classes and asso...
Antipattern Example: Poltergeists From:  www.antipatterns.com
Antipattern Example: Fixing Poltergeists <ul><li>Refactor to eliminate irrelevant classes  </li></ul><ul><ul><li>Delete ex...
Good Design Properties <ul><li>Hierarchical : A good design should be organized into a well-designed hierarchy of componen...
Good Design Properties <ul><li>Independent : Group similar things together; limit the amount of “special knowledge” that u...
Good Design Properties <ul><li>Simple Interfaces:  Endless flexibility adds complexity. Complex interfaces mean: </li></ul...
Summary:  Software Design <ul><li>Good software designers are experienced software designers </li></ul><ul><ul><li>Given a...
Demystifying SOA <ul><li>Service-Oriented architecture is the latest “buzz” in the information technology and enterprise a...
SOA – Its an Architecture, Design and Instantiation Approach <ul><li>Understanding SOA requires one to answer the followin...
Traditional versus SOA applications – a line and box view… <ul><li>Applications designed in conjunction with an SOA style ...
What is a service? <ul><li>Service ( also application service ): An application function that (a) within each request, enc...
What is a service? – Technically… <ul><li>Service boundaries are explicit </li></ul><ul><ul><li>Service invocation based o...
What is a service? – Technically… <ul><li>Services share schema and contract, not class </li></ul><ul><ul><li>Services adv...
What is a service? – Technically… <ul><li>Service compatibility is determined based on policy </li></ul><ul><ul><li>Due to...
Why SOA – Another Layer of Abstraction <ul><li>OO abstractions were introduced to deal with the complexity of managing fun...
Activates to consider when designing an SOA  [ref:   http://www.webservices.org/index.php/ws/content/view/full/55441] SOA ...
Logical Layering for SOA  [ref:   http://www.webservices.org/index.php/ws/content/view/full/55441] (e.g., ESB)
Services are another layer of Abstraction  <ul><li>Services are special types of  components , having a  published interfa...
SOA Design Principles <ul><li>Course-Grained </li></ul><ul><li>Interface-based Design </li></ul><ul><li>Discoverable </li>...
Patterns for SOA… <ul><li>SOA-design is often done using the following integration and orchestration architecture patterns...
Upcoming SlideShare
Loading in …5
×

© Drexel University Software Engineering Research Group (SERG)

1,123 views

Published on

  • Be the first to comment

  • Be the first to like this

© Drexel University Software Engineering Research Group (SERG)

  1. 1. CS 575: Software Design Introduction
  2. 2. Software Design Structural Packaging Behavioral Infrastructure Requirements, Test/Validation Criteria A software design is a precise description of a system, using a variety of different perspectives…
  3. 3. Expressing A Software Design <ul><li>Similar to an architects blueprint </li></ul><ul><li>A model is an abstraction of the underlying problem </li></ul><ul><li>Designs should be modeled, and expressed as a series of views </li></ul><ul><li>Helpful to use a modeling language such as UML </li></ul>Software Designs are complicated, therefore, they must be modeled…
  4. 4. Modeling as a Design Technique <ul><li>Designs are too complicated to develop from scratch </li></ul><ul><li>Good designs tend to be build using models… </li></ul><ul><ul><li>1) Abstract different views of the system </li></ul></ul><ul><ul><li>2) Build models using precise notations (e.g., UML) </li></ul></ul><ul><ul><li>3) Verify that the models satisfy the requirements </li></ul></ul><ul><ul><li>4) Gradually add details to transform the models into the design </li></ul></ul>
  5. 5. Modeling as a Design Technique Models Lets Build this System… Incremental Refinement Design Lets Start Building this System…
  6. 6. Modeling as a Design Technique - Improved Models Lets Build this System… Incremental Refinement Design Lets Start Building this System… Frameworks, Patterns, Templates, etc.
  7. 7. Modeling Designs… Designing With Models Design Very Complicated To Understand Modeling Tool Model Repository Visualization
  8. 8. UML – A modeling Notation for Design Structural Packaging/Implementation Behavioral Infrastructure/ Environment Requirements, Test/Validation Criteria Use Cases Class Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams Package Diagrams Component Diagrams Deployment Diagrams
  9. 9. Software Architecture <ul><li>According to Shaw and Garlan… The Software Architecture of a system consists of a description of the system elements, interactions between the system elements, patterns that guide the system elements, and constraints on the relationships between system elements. </li></ul><ul><ul><li>Its a more abstract view of the design </li></ul></ul><ul><ul><li>Its helpful for communication and complexity management </li></ul></ul><ul><li>Problem: There is no standard definition – see http://www.sei.cmu.edu/architecture/definitions.html </li></ul>
  10. 10. The Software Architecture “Stack” Software Architecture Subsystem Decomposition Subsystem Dependencies Subsystem Interfaces Module/Class Decompositions Module/Class Dependencies Module/Class Interfaces Data Structures Algorithms
  11. 11. The Software Architecture “Stack” Software Architecture Subsystem Decomposition Subsystem Dependencies Subsystem Interfaces Module/Class Decompositions Module/Class Dependencies Module/Class Interfaces Data Structures Algorithms High-Level (Abstract) Design Low-Level (Detailed) Design
  12. 12. Why do we design… <ul><li>Manage complexity </li></ul><ul><li>Validation of delivered software </li></ul><ul><li>Simplify future maintenance </li></ul><ul><li>A mechanism for communication between domain experts and technical professionals </li></ul><ul><li>Enables Visualization </li></ul><ul><li>Enables project team members to work concurrently </li></ul><ul><ul><li>Partitioning the work effort with limited overlap </li></ul></ul><ul><ul><li>Example: Concurrently developing test cases while the code is being development </li></ul></ul>A software design is not necessary for trivial systems, but for large systems a design is essential
  13. 13. Why is design so hard… <ul><li>Software design can’t be taught, but principles of good design can </li></ul><ul><li>There are degrees of good and bad design, but its hard to say if a design is correct or not </li></ul><ul><li>The underlying assumptions and requirements that support the design change </li></ul><ul><li>A design is like wine, it takes a long time to see if it is good or not </li></ul>
  14. 14. How Humans Design... From “Wicked Problems and Social Complexity” http://www.cognexus.org/id42.htm , Jeff Conklin
  15. 15. Software Design (for non-trivial applications) is a “Wicked Problem” <ul><li>“ You don't understand the problem until you have developed a solution” </li></ul><ul><ul><li>As candidate solutions are developed, new aspects of the problem are exposed, requiring the solution to be adjusted </li></ul></ul><ul><li>“ There is no stopping rule” </li></ul><ul><ul><li>There can be no “solution” without a formal definition of the problem. Stopping happens when you run out of time, money, resources, etc. </li></ul></ul><ul><li>“ Solutions to wicked problems are not 'right' or 'wrong'” </li></ul><ul><ul><li>Can be considered “good enough”, or “not satisfactory” </li></ul></ul>
  16. 16. Software Design (for non-trivial applications) is a “Wicked Problem” <ul><li>“ Every wicked problem is unique and novel” </li></ul><ul><ul><li>There are so many factors and conditions, all embedded in a dynamic social context, that no two wicked problems are alike, and the solutions to them will always be custom designed and fitted. </li></ul></ul><ul><li>“ Every solution to a wicked problem is a one shot operation” </li></ul><ul><ul><li>You cannot learn about the problem without trying a solution, but each solution considered is so complex and expensive that trying more than one is not feasible </li></ul></ul><ul><li>“ Wicked problems have no given alternative solutions” </li></ul><ul><ul><li>Its a matter of creativity to devise potential solutions, and a matter of judgement to determine which are valid </li></ul></ul>
  17. 17. Why what you learned in software engineering 101 does not work... <ul><li>From Raymonde Guindon's paper “Designing the Design Process: Exploiting Opportunistic Thoughts” </li></ul><ul><ul><li>Top-down decomposition is problematic in the early stages of design due to the ill-structuredness the problems considered </li></ul></ul><ul><ul><li>Opportunistic design approaches are used in practice where partial solutions are discussed as new requirements are uncovered </li></ul></ul><ul><ul><li>A top-down decomposition appears to be a special case for well-structured problems when the designer already knows the correct decomposition </li></ul></ul>
  18. 18. Design Methodologies Extreme Programming Waterfall Iterative
  19. 19. Software Development Methodology <ul><li>A Methodology is: </li></ul><ul><ul><li>A Process </li></ul></ul><ul><ul><ul><li>What happens over time </li></ul></ul></ul><ul><ul><ul><li>Coupled to the Software Development Lifecycle (SDLC) </li></ul></ul></ul><ul><ul><li>A Management Approach </li></ul></ul><ul><ul><ul><li>What is needed to move from one step to another </li></ul></ul></ul><ul><li>Helps with the project management aspects of a software development project </li></ul>
  20. 20. Modeling Emphasis for Different Design Approaches Component Oriented Traditional/ Structured Object Oriented Data Structure Function
  21. 21. Jumpstarting Design Starting from scratch “blank screen” is tough. Components of a design toolbox – Templates, Patterns, Reference Architectures, Frameworks, and so on… ?
  22. 22. Example: Jakarta Struts Presentation Framework
  23. 23. Example: J2EE Architecture Patterns Source: http://java.sun.com/ blueprints/ corej2eepatterns/Patterns/
  24. 24. Example: Intercepting Filter Pattern Architectural Pattern <ul><li>Problem: Preprocessing and post-processing of a client Web request and response are required </li></ul><ul><ul><li>When a request enters a Web application, it often must pass several entrance tests prior to the main processing stage: </li></ul></ul><ul><ul><ul><li>Has the client been authenticated? </li></ul></ul></ul><ul><ul><ul><li>Does the client have a valid session? </li></ul></ul></ul><ul><ul><ul><li>Is the client's IP address from a trusted network? </li></ul></ul></ul><ul><ul><ul><li>Does the request path violate any constraints? </li></ul></ul></ul><ul><ul><ul><li>What encoding does the client use to send the data? </li></ul></ul></ul><ul><ul><ul><li>Do we support the browser type of the client? </li></ul></ul></ul><ul><li>The key to solving this problem in a flexible and unobtrusive manner is to have a simple mechanism for adding and removing processing components, in which each component completes a specific filtering action. </li></ul>
  25. 25. Design Patterns <ul><li>Example: Observer Pattern </li></ul><ul><ul><li>Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically </li></ul></ul>Note: Design pattern references often include sample code in a variety of languages to illustrate how to use the pattern.
  26. 26. What’s good about Patterns <ul><li>They solve common problems in a “proven” way </li></ul><ul><li>They tend not to be implementation specific </li></ul><ul><li>They tend to be classified in a common way – context, forces, examples, etc </li></ul><ul><li>They embody good design principles </li></ul><ul><ul><li>Example: Loose Coupling </li></ul></ul>
  27. 27. Design Quality <ul><li>Software design “quality”, as with other ideas on quality, is an elusive concept: </li></ul><ul><li>It depends on priorities of your company and the customers: </li></ul><ul><ul><li>fastest to implement </li></ul></ul><ul><ul><li>easiest to implement </li></ul></ul><ul><ul><li>easiest to maintain, “evolve”, port </li></ul></ul><ul><ul><li>most efficient/reliable/robust end-product. </li></ul></ul>
  28. 28. How to “Fix” A Software Design <ul><li>Many times the source code is the only up-to-date documentation for a software system </li></ul><ul><ul><li>Must be able to recover the design to some extent </li></ul></ul><ul><ul><li>Must be able to “improve” the design where appropriate </li></ul></ul>
  29. 29. Improving Existing Designs - Refactoring <ul><li>See Martin Fowler’s Book </li></ul><ul><li>What is Refactoring: </li></ul><ul><ul><li>Refactoring is a technique to restructure code in a disciplined way </li></ul></ul><ul><ul><li>Used to improve a system design in any number of ways </li></ul></ul><ul><ul><li>Pattern/Template based process </li></ul></ul><ul><ul><li>Automated tools exist </li></ul></ul>Refactoring is a behavior preserving transformation of the source code…
  30. 30. Example: Refactoring – PushDown Method Bill +setName() +getAddress() … +send() Bill +setName() +getAddress() … #send() EBill +send() MailBill +send() Before After Note: There are many ways to do this type of refactoring – this is just one example.
  31. 31. Anti-Patterns (plus Refactoring) <ul><li>AntiPatterns are Negative Solutions that present more problems than they address </li></ul><ul><li>AntiPatterns are a natural extension to design patterns </li></ul><ul><li>AntiPatterns bridge the gap between architectural concepts and real-world implementations. </li></ul><ul><li>Understanding AntiPatterns provides the knowledge to prevent or recover from them </li></ul><ul><ul><li>Recovery can be via Refactoring </li></ul></ul>From: www.antipatterns.com
  32. 32. Antipattern Example: Poltergeists <ul><li>Proliferation of classes [Riel 96] </li></ul><ul><li>Spurious classes and associations </li></ul><ul><ul><li>Stateless, short-lifecycle classes </li></ul></ul><ul><ul><li>Classes with few responsibilities </li></ul></ul><ul><ul><li>Transient associations </li></ul></ul><ul><li>Excessive complexity </li></ul><ul><li>Unstable analysis and design models </li></ul><ul><li>Analysis paralysis </li></ul><ul><li>Divergent design and implementation </li></ul><ul><li>Poor system performance </li></ul><ul><li>Lack of system extensibility </li></ul>From: www.antipatterns.com
  33. 33. Antipattern Example: Poltergeists From: www.antipatterns.com
  34. 34. Antipattern Example: Fixing Poltergeists <ul><li>Refactor to eliminate irrelevant classes </li></ul><ul><ul><li>Delete external classes (outside the system) </li></ul></ul><ul><ul><li>Delete classes with no domain relevance </li></ul></ul><ul><li>Refactor to eliminate transient “data classes” </li></ul><ul><li>Refactor to eliminate “operation classes” </li></ul><ul><li>Refactor other classes with short lifecycles or few responsibilities </li></ul><ul><ul><li>Move into collaborating classes </li></ul></ul><ul><ul><li>Regroup into cohesive larger classes </li></ul></ul>From: www.antipatterns.com
  35. 35. Good Design Properties <ul><li>Hierarchical : A good design should be organized into a well-designed hierarchy of components. </li></ul><ul><li>Modular : Separate distinct concerns (dataand processing) into distinct containers (i.e.,subsystems, modules, and/or classes). Hide implementation details and provide clean, simple interfaces for each container. </li></ul>
  36. 36. Good Design Properties <ul><li>Independent : Group similar things together; limit the amount of “special knowledge” that unrelated components may share. If you change your mind about something, the impact will be localized . </li></ul>
  37. 37. Good Design Properties <ul><li>Simple Interfaces: Endless flexibility adds complexity. Complex interfaces mean: </li></ul><ul><ul><li>hard to understand by users and developers ( e.g., Unix man page syndrome) </li></ul></ul><ul><ul><li>many possible variations of use </li></ul></ul><ul><ul><li>inconvenient to change interface in order to eliminate “bad options”. </li></ul></ul><ul><li>You can get away with “flexible interfaces” in a low-level localized setting, but the larger the scale, the simpler the interface should be. </li></ul>
  38. 38. Summary: Software Design <ul><li>Good software designers are experienced software designers </li></ul><ul><ul><li>Given a design, and experienced designer can tell you: </li></ul></ul><ul><ul><ul><li>What’s good, What’s Bad, and provide suggestions for improvement </li></ul></ul></ul><ul><ul><li>Patterns and Frameworks are very helpful to software designers </li></ul></ul><ul><li>Good software designs are based on good design principles </li></ul>
  39. 39. Demystifying SOA <ul><li>Service-Oriented architecture is the latest “buzz” in the information technology and enterprise application domains </li></ul><ul><li>There is a lot of hype, buzzwording and misconception around SOA </li></ul><ul><li>We will place a good bit of emphasis in this course examining at SOA to try to understand its pro’s and con’s from an application architecture and design perspective. </li></ul>
  40. 40. SOA – Its an Architecture, Design and Instantiation Approach <ul><li>Understanding SOA requires one to answer the following questions: </li></ul><ul><ul><li>What is a service oriented architecture? </li></ul></ul><ul><ul><li>What is a service? </li></ul></ul><ul><ul><li>How do I design an application that adheres to a SOA? </li></ul></ul><ul><ul><li>How do I implement an application designed using SOA principles? </li></ul></ul>
  41. 41. Traditional versus SOA applications – a line and box view… <ul><li>Applications designed in conjunction with an SOA style are easier to design, implement, maintain and extend due to the loose coupling of components that reside in different services </li></ul><ul><ul><li>The pieces (services) in an SOA are designed with a courser granularity than an design based on traditional components, making the system simpler to deal with </li></ul></ul><ul><ul><li>The messaging interfaces between the services in an SOA have structure and semantics allowing them to be intelligently routed and provisioned based on application-specified policies </li></ul></ul>
  42. 42. What is a service? <ul><li>Service ( also application service ): An application function that (a) within each request, encompasses a complete parcel of work (business or technical), (b) may stand on its own or be part of a larger set of functions that constitute a larger service but its scope is such that each request leaves the system in a long-term steady state, (c) is designed for and provides a network-accessible interface and (d) is designed to receive requests from any source, making no assumptions as to the functional correctness (syntactic or semantic) of an incoming request. </li></ul>
  43. 43. What is a service? – Technically… <ul><li>Service boundaries are explicit </li></ul><ul><ul><li>Service invocation based on message passing and not method invocation </li></ul></ul><ul><li>Services are autonomous </li></ul><ul><ul><li>Services can be deployed and/or extended independently of the service consumers (i.e., applications) </li></ul></ul><ul><ul><li>Services can be developed in any language since the binding is in the form of an encoded message in a standard format </li></ul></ul>
  44. 44. What is a service? – Technically… <ul><li>Services share schema and contract, not class </li></ul><ul><ul><li>Services advertise a contract that describes the structure (schema) of messages it can send and/or receive as well as some degree of ordering constraints over those messages. </li></ul></ul><ul><ul><li>Interfaces are defined in terms of a schema and not binary classes </li></ul></ul><ul><ul><li>Example: WSDL in Web Services </li></ul></ul>
  45. 45. What is a service? – Technically… <ul><li>Service compatibility is determined based on policy </li></ul><ul><ul><li>Due to the tightly coupled nature of OO and Component designs, they assume that structural compatibility implies semantic compatibility </li></ul></ul><ul><ul><li>Structural compatibility in SOA is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy. </li></ul></ul><ul><ul><li>Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. </li></ul></ul>
  46. 46. Why SOA – Another Layer of Abstraction <ul><li>OO abstractions were introduced to deal with the complexity of managing functions independent of data </li></ul><ul><li>CBD abstractions were introduced to deal with the complexity of distribution, packaging, and deployment </li></ul><ul><li>SOA abstractions were introduced to create the notion of a network-aware, single instance component that can participate in a both synchronous and asynchronous business process </li></ul>
  47. 47. Activates to consider when designing an SOA [ref: http://www.webservices.org/index.php/ws/content/view/full/55441] SOA separates the concerns of the service consumer and the service provider.
  48. 48. Logical Layering for SOA [ref: http://www.webservices.org/index.php/ws/content/view/full/55441] (e.g., ESB)
  49. 49. Services are another layer of Abstraction <ul><li>Services are special types of components , having a published interface that consists of a subset of one or more public component interfaces that collectively defines the service boundary </li></ul><ul><li>Components are built from a collection of objects where the emphasis is on creating a deployable package that enables the component to execute in a managed application server container such as .Net or J2EE/WebSphere </li></ul><ul><li>Objects are compiled code, developed in a specific programming language, that represent the most granular element of the system’s implementation </li></ul>
  50. 50. SOA Design Principles <ul><li>Course-Grained </li></ul><ul><li>Interface-based Design </li></ul><ul><li>Discoverable </li></ul><ul><li>Single Instance </li></ul><ul><li>Loosely Coupled </li></ul><ul><li>Asynchronous </li></ul>
  51. 51. Patterns for SOA… <ul><li>SOA-design is often done using the following integration and orchestration architecture patterns: </li></ul><ul><ul><li>Value-Object </li></ul></ul><ul><ul><li>Proxy </li></ul></ul><ul><ul><li>Facade </li></ul></ul><ul><ul><li>Business Delegate (perhaps with factory) </li></ul></ul><ul><ul><li>Adapter </li></ul></ul><ul><ul><li>Layer </li></ul></ul>We will talk about these in a later lecture…

×