The document discusses the goals of good software design, which include producing software that is correct, robust, flexible, reusable, efficient, and reliable/usable. It defines these terms, explaining that correct software satisfies requirements, robust software tolerates misuse, flexible software can adapt to changing requirements, reusable software cuts production costs, and efficient software makes good use of resources. It also discusses modeling languages, software requirements specifications, class diagrams, and depicting classes in diagrams.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online from Scribd
The document discusses the goals of good software design, which include producing software that is correct, robust, flexible, reusable, efficient, and reliable/usable. It defines these terms, explaining that correct software satisfies requirements, robust software tolerates misuse, flexible software can adapt to changing requirements, reusable software cuts production costs, and efficient software makes good use of resources. It also discusses modeling languages, software requirements specifications, class diagrams, and depicting classes in diagrams.
The document discusses the goals of good software design, which include producing software that is correct, robust, flexible, reusable, efficient, and reliable/usable. It defines these terms, explaining that correct software satisfies requirements, robust software tolerates misuse, flexible software can adapt to changing requirements, reusable software cuts production costs, and efficient software makes good use of resources. It also discusses modeling languages, software requirements specifications, class diagrams, and depicting classes in diagrams.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online from Scribd
The document discusses the goals of good software design, which include producing software that is correct, robust, flexible, reusable, efficient, and reliable/usable. It defines these terms, explaining that correct software satisfies requirements, robust software tolerates misuse, flexible software can adapt to changing requirements, reusable software cuts production costs, and efficient software makes good use of resources. It also discusses modeling languages, software requirements specifications, class diagrams, and depicting classes in diagrams.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online from Scribd
Download as pptx, pdf, or txt
You are on page 1/ 25
Goals of Software Design
Design faces many challenges to produce a good product, e.g. shifting requirements. But what do we mean by good ? We need some clear goals here
Good design leads to software that is: 1. Correct does what it should 2. Robust tolerant of misuse, e.g. faulty data 3. Flexible adaptable to shifting requirements 4. Reusable cut production costs for code 5. Efficient good use of processor and memory Also should be Reliable and Usable
Correctness Software is correct, if it satisfies its requirements. A primary goal, incorrect software may look good, but will be poor or worse. Requirements are divided into functional (what it does) and non-functional (how it does it, etc.)
Robustness A design or system is robust if it tolerates misuse without catastrophic failure. fault-tolerant. Includes bad data, bad use, bad environment, bad programming.
Robustness achieved in many ways: Use data abstraction and encapsulation
Create ADTs and simple interfaces Shield from data corruption
Initialize variables Qualify all inputs (e.g. range check)
Same as precondition checking
Qualify all formal parameters to a method Qualify invariants
(e.g. non-null pointer, not end_of_file )
Qualify postconditions
Flexibility Requirements may change during or after the project. Obtaining more of whats present e.g. more kinds of different bank accounts Adding new kinds of functionality e.g. add internet banking to teller functionality Changing functionality e.g. allow withdrawals to create an overdraft
Reusability Aim: cut cost of code production over 1 or more projects. Reuse object code (see later discussion of component technologies) Reuse source code see next slides Reuse assemblies of related classes, e.g. software frameworks Reuse patterns of designs see previous!
Efficiency Aim: Make greatest use of the processing power, memory size, network speed, etc. But all these things are getting cheaper! But applications are getting bigger! Efficiency is often against the first 4 goals!
What Is A Model ? A Representation of an object, a system, or an idea in some form other than that of the entity itself. (Shannon)
Introduction
Types of Models: Physical (Scale models, prototype plants,) Mathematical (Analytical queueing models, linear programs, simulation)
Introduction
10
MODELLING GENERAL PURPOSE LANGUAGES
Advantages: Little or no additional software cost Universally available (portable) No additional training
Disadvantages: Every model starts from scratch Very little reusable code Long development cycle for each model Difficult verification phase
Introduction
11
What is software requirements Specification
A software requirements specification (SRS) describes the requirements of a software product -- what it must do in order to function as expected. Realize that despite using the term "requirements," an SRS really is high-level design how of a product whose expected functioning is a presumed way to satisfy the REAL business requirements deliverable whats that provide value when satisfied. The software can work as expected but won't provide value unless it actually satisfies the REAL business requirements
The Software Requirements Specification
After review of the customers System Spec. After educated analysis Preliminary design A technical, software approach Results in permission to detail-design and code
From the customers perspective
How smart people are going to solve the problem that was stated in the System Spec. A contract, more or less Is it doable? Technically On time Under budget
Major Modules to 2 or 3 levels of supervision low level utilities if they touch hardware or the environment
Risk Assessment Technical Risks hardware software interfaces build vs. buy
Schedule Risks budget calendar personnel level of expertise required
Major Module Descriptions
Supervisory / Executive Classes, Major Objects, and Libraries Build vs. Buy Interfaces Module to Module SW to HW Control to Data
Low Level Utilities
Drivers
What is Class Diagram?
Class diagrams are aspects that describe a static design of the objects, and their relationships to each other, in an application. During analysis, class diagrams may just be the names of objects and how they interact, but as the design develops the details of each class, including attributes and methods, are displayed in the diagram.
Classes ClassName attributes operations
A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Graphically, a class is rendered as a rectangle, usually including its name, attributes, and operations in separate, designated compartments.
Class Names ClassName attributes operations The name of the class is the only required tag in the graphical representation of a class. It always appears in the top-most compartment.
Class Attributes Person name : String address : Address birthdate : Date ssn : Id An attribute is a named property of a class that describes the object being modeled. In the class diagram, attributes appear in the second compartment just below the name-compartment.
Class Attributes (Contd)
Attributes are usually listed in the form:
Person name : String address : Address birthdate : Date / age : Date ssn : Id
attributeName : Type A derived attribute is one that can be computed from other attributes, but doesnt actually exist. For example, a Persons age can be computed from his birth date. A derived attribute is designated by a preceding / as in: / age : Date
Class Attributes (Contd)
Person + name : String # address : Address # birthdate : Date / age : Date - ssn : Id Attributes can be: + public # protected - private / derived
Class Operations Person name : String address : Address birthdate : Date ssn : Id eat sleep work play Operations describe the class behavior and appear in the third compartment.
Software Design (UML)
Depicting Classes When drawing a class, you neednt show attributes and operation in every diagram. Person Person Person name : String birthdate : Date ssn : Id
