Outline Design
Software Engineering
Lecture 10 - 12
Dr. Mohammad Jaudet, DEE
Pakistan Institute of Engineering and Applied Sciences
October, 2010
Dr. Mohammad Jaudet, October, 2010 - February 2011. 1
docsity.com
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Software Design Activity-Design and Processes in Software Engineering-Lecture Slides, Slides of Software Engineering
Prof. Ajeeta Vrajanadan delivered this lecture at Baddi University of Emerging Sciences and Technologies for Software Engineering course. Its main points are: Software, System, Decomposed, Module, Interface, Design, Techniques, UML, Collection, Design, Patterns
Typology: Slides
2011/2012
1 / 45
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Software Design Activity-Design and Processes in Software Engineering-Lecture Slides and more Slides Software Engineering in PDF only on Docsity!
Software Engineering
Lecture 10 - 12
Dr. Mohammad Jaudet, DEE [email protected]
Pakistan Institute of Engineering and Applied Sciences
October, 2010
Outline of the Lecture 10 - 12
What is design How can a system be decomposed into modules What is a module’s interface What are the main relationships among modules Prominent software design techniques and information hiding The UML collection of design notations Design of concurrent and distributed software Design patterns Architectural styles Component based software engineering
Two meanings of "design" activity in our context
Activity that acts as a bridge between requirements and the implementation of the software Activity that gives a structure to the artifact e.g., a requirements specification document must be designed must be given a structure that makes it easy to understand and evolve
The software design activity
Defined as system decomposition into modules Produces a Software Design Document describes system decomposition into modules Often a software architecture is produced prior to a software design
Two important goals
Design for change (Parnas) designers tend to concentrate on current needs special effort needed to anticipate likely changes Product families (Parnas) think of the current system under design as a member of a program family
Sample likely changes? (1)
Algorithms e.g., replace inefficient sorting algorithm with a more efficient one Change of data representation e.g., from binary tree to a threaded tree (see example) Approximately 17% of maintenance costs attributed to data representation changes (Lientz and Swanson, 1980)
Sample likely changes? (2)
Change of underlying abstract machine new release of operating system new optimizing compiler new version of DBMS ... Change of peripheral devices Change of "social" environment new tax regime EURO vs national currency in EU Change due to development process (transform prototype into product)
Product families
Different versions of the same system e.g. a family of mobile phones members of the family may differ in network standards, end-user interaction languages, ... e.g. a facility reservation system for hotels: reserve rooms, restaurant, conference space, ..., equipment (video beamers, overhead projectors, ...) for a university many functionalities are similar, some are different (e.g., facilities may be free of charge or not)
Sequential completion: the wrong way
Design first member of product family Modify existing software to get next member products
Sequential completion:a graphical view
Module
A well-defined component of a software system A part of a system that provides a set of services to other modules Services are computational elements that other modules may use
Questions
How to define the structure of a modular system? What are the desirable properties of that structure?
Relations
Transitive closure r+^ of r Mir+Mj iff MirMj or ∃Mk in S s.t. MirMk and Mkr+Mj (We assume our relations to be irreflexive, i.e., MirMi can not hold) r is a hierarchy iff there are no two elements Mi, Mj s.t. Mir+Mj ∧ Mjr+Mi
Relations
Relations can be represented as graphs A hierarchy is a DAG (directed acyclic graph)