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