1 / 38

Software Design

Understand the phases of software design - from architectural to detailed, including abstract and interface design. Learn about cohesion, coupling, and adaptability for quality design.

madelynd
Download Presentation

Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Design AITI GP John Paul Vergara

  2. What is Design? • Design is the activity of specifying a solution to a problem • Contrast this against other software engineering phases • Analysis: understanding and specifying the problem (requirements) • Implementation: system construction

  3. Goal of Software Design • To achieve sufficient agreement on interface definition and internal structure that implementation may proceed in parallel teams.

  4. Stages in SW Design • Architectural Design • Abstract Specification • Interface Design • Component Design • Detailed Design *Reference: Sommerville, Chapter 12

  5. Architectural Design • Identify Subsystems and Modules • Example: Program Submission System • Server • Teacher Interface • Student Interface

  6. Architectural Design, continued • Design information provided is minimal • System is simply decomposed into interacting subsystems or modules • Making global and local decisions about planned implementation based on constraints, non-functional requirements and available alternatives • Has general applicability

  7. Structure Communication Distribution Persistence Security Error Handling Recovery Use or Reuse of existing hardware and software configurations “Obvious” areas of concern for architectural design

  8. Abstract Specification • Identify services and constraints per subsystem • Example: Server • set up a class • set up a project • submit a program • Note: descriptions of services are informal

  9. Interface Design • Per subsystem, specify its interface • collection of available functions/methods for use by other subsystems • Consistent with Encapsulation • Example: Server • function: set_up_class • parameters: catnum, section, list of students (id#’s and names)

  10. Interface Specification • Services per subsystem are formally specified • Goal: provide unambiguous information regarding extent of external interaction • parameters/inputs, return values/outputs • Design and implementation details of the subsystem are still hidden

  11. Component Design • Within a subsystem • determine components • per component, identify services/interfaces • Understand interaction between components at the level of the subsystem • OO Design: components are classes • Design models (using the UML, for example) are most useful at this level

  12. Detailed Design • Specify data structures and algorithms (for methods) of the individual components (classes) • Generally still implementation-independent • Although though in practice, specific language features are used • Techniques: Pseudocode, flowcharts, others

  13. Design Work Products • System Architecture • Application Programming Interfaces • Target Environment (addressing non-functional requirements) • Subsystem Model • Design Object Model - static model representing structure of classes and relationships with each other

  14. Design Work Products continued... • Design Object Interaction Diagrams - graphically depict collaborations between objects • Design State Models - represent dynamic behavior of design classes and are done for all classes that have strong state dependent object behavior

  15. Design Quality • Cohesion • Coupling • Understandability • Adaptability *Reference: Section 12.3 of Sommerville

  16. Cohesion • Extent of relationship between parts of a component • High cohesion is desirable • Single logical t (or “theme”) • all parts should contribute to the function • Levels of cohesion (p. 218) • coincidental cohesion (weakest) • functional cohesion (strongest)

  17. Coupling • Dependence between units of a subsystems or components • High coupling generally undesirable • units fully depend on each other • sensitive to change • convenient/necessary only for small components

  18. Understandability • Cohesion and Coupling • understanding a component independently • Naming • reflects real-world intuition • Documentation • Complexity • algorithms

  19. Adaptability • Sensitivity to change • are changes in design easy? • Loosely coupled components • Self-contained components

  20. Object-OrientedDesign Notation CS 123/CS 231

  21. References • UML in a Nutshell • UML Distilled, by Martin Fowler • Chapters 3, 4, 6, and 8 • Supplementary References: • Chapter 14 of Sommerville • Chapter 22 of Pressman

  22. Component Design and Detailed Design • Component Design • For each subsystem determine components, and services/interface per component • OO Design: components are classes • Detailed Design • Determine attributes of classes and relationships between the classes • Determine functionality of each class and interactions between classes

  23. Object-Oriented Modeling • UML: Unified Modeling Language • OO Modeling Standard • Booch, Jacobson, Rumbaugh • UML is used to visualize, specify, construct and document the artifacts of a software intensive system

  24. Building Blocks of the UML • Things • the abstractions • Relationships • tie the “things” together • Diagrams • group interesting collections of things

  25. UML Diagrams • What is depicted? • Class details and static relationships • System functionality • Object interaction • State transition within an object

  26. Some UML Modeling Techniques • Class Diagrams • Use Cases/Use Case Diagrams • Interaction Diagrams • Sequence Diagrams • Collaboration Diagrams • State Diagrams • Activity Diagram

  27. Example:Class Diagram FFCounter totalcash totalorders PriceChecker getPrice() pc counters 5 FastFood Restaurant

  28. Example:Use Case Diagram LIBRARY SYSTEM Facilitate Checkout Search for Book Borrower Librarian Facilitate Return

  29. Example:Interaction Diagram 2: checkIfAvailable() Checkout Screen :Book 1: checkIfDelinquent() 3: borrowBook() 4: setBorrower() :Borrower

  30. Example:State Diagram (Book) start Reserved Borrowed New Librarian activates book as available Borrower returns book Available

  31. Object-Oriented Design Models • Static Model : interested in the structure • Class Diagrams • Dynamic Model : interested in the behavior • Use Cases, Interaction Diagrams, State Diagrams, others

  32. OO Static Model • Classes and Class Diagrams • Names (attributes and methods) • Visibility(private,public,protected) • Scope (abstract, concrete…) • Relationships • Dependency : change to one affects the other • Association (includes aggregation and composition) : structural relationship describing connection between the objects

  33. Relationships continued... • Generalization : inheritance • Realization : a classifier specifies a contract that another classifier guarantees to carry out (e.g., interfaces and classes that realize them)

  34. OO Dynamic Model • Goal: Represent • Object behavior • Object interaction • Traditional/Procedural Dynamic Modeling • Data Flow Diagrams (DFDs) • Problem: Processes separate from data • Need modeling notation that highlight tight relationship between data & processes

  35. DFD Example(Inventory Management) Accept and Post Delivery Delivery info Transaction Item Master

  36. OO Counterpart:Object Interaction new (delivery info) Encoder :Transaction post (item count) :Item Master

  37. Building anOO Dynamic Model • Identify use cases • Describe each use case through an interaction diagram • For state dependent objects, can provide state diagrams • Derive implied methods (and attributes) • Define flow of control, sequence of messages

  38. What’s Next? • Need to understand the notation • Make sure it helps the software development process • When to use the UML techniques • Primarily when specifying OO design • Formal means of communication across the different software development stages

More Related