Software Design AITI GP John Paul Vergara
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
Goal of Software Design To achieve sufficient agreement on interface definition and internal structure that implementation may proceed in parallel teams.
Stages in SW Design Architectural Design Abstract Specification Interface Design Component Design Detailed Design *Reference: Sommerville, Chapter 12
Architectural Design Identify Subsystems and Modules Example: Program Submission System Server Teacher Interface Student Interface
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
“Obvious” areas of concern for architectural design Structure Communication Distribution Persistence Security Error Handling Recovery Use or Reuse of existing hardware and software configurations
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
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)
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
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
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
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
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
Design Quality Cohesion Coupling Understandability Adaptability *Reference: Section 12.3 of Sommerville
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)
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
Understandability Cohesion and Coupling Naming Documentation understanding a component independently Naming reflects real-world intuition Documentation Complexity algorithms
Adaptability Sensitivity to change Loosely coupled components are changes in design easy? Loosely coupled components Self-contained components
Object-Oriented Design Notation CS 123/CS 231
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
Component Design and Detailed 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
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
Building Blocks of the UML Things the abstractions Relationships tie the “things” together Diagrams group interesting collections of things
UML Diagrams What is depicted? Class details and static relationships System functionality Object interaction State transition within an object
Some UML Modeling Techniques Class Diagrams Use Cases/Use Case Diagrams Interaction Diagrams Sequence Diagrams Collaboration Diagrams State Diagrams Activity Diagram
Example: Class Diagram FFCounter totalcash totalorders PriceChecker getPrice() pc counters 5 FastFood Restaurant
Example: Use Case Diagram LIBRARY SYSTEM Facilitate Checkout Search for Book Borrower Librarian Facilitate Return
Example: Interaction Diagram 2: checkIfAvailable() Checkout Screen :Book 1: checkIfDelinquent() 3: borrowBook() 4: setBorrower() :Borrower
Example: State Diagram (Book) start Reserved Borrowed New Librarian activates book as available Borrower returns book Available
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
OO Static Model Classes and Class Diagrams Relationships 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
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)
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
DFD Example (Inventory Management) Accept and Post Delivery Delivery info Transaction Item Master
OO Counterpart: Object Interaction new (delivery info) Encoder :Transaction post (item count) :Item Master
Building an OO 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
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