which satisfies software requirements

Slides:



Advertisements
Similar presentations
Lecture 6: Software Design (Part I)
Advertisements

ARCHITECTURES FOR ARTIFICIAL INTELLIGENCE SYSTEMS
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Design Concepts and Principles
Software Design Deriving a solution which satisfies software Speficitaion.
Software Engineering Software Design Slide 1 Software Engineering Software Design.
Software Design Hoang Huu Hanh, Hue University hanh-at-hueuni.edu.vn.
Lecturer: Sebastian Coope Ashton Building, Room G.18 COMP 201 web-page: Lecture.
Analysis Stage (Phase I) The goal: understanding the customer's requirements for a software system. n involves technical staff working with customers n.
1 Lecture 5 Introduction to Software Engineering Overview  What is Software Engineering  Software Engineering Issues  Waterfall Model  Waterfall Model.
Course Instructor: Aisha Azeem
Software Design Deriving a solution which satisfies software requirements.
Architectural Design Establishing the overall structure of a software system Objectives To introduce architectural design and to discuss its importance.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 11 Slide 1 Architectural Design.
Chapter 7: Architecture Design Omar Meqdadi SE 273 Lecture 7 Department of Computer Science and Software Engineering University of Wisconsin-Platteville.
CSE 303 – Software Design and Architecture
SOFTWARE DESIGN (SWD) Instructor: Dr. Hany H. Ammar
SOFTWARE DESIGN.
1 Software Design Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13, 5 th edition and Ch. 10, 6 th edition.
SOFTWARE DESIGN Design Concepts Design is a meaningful engineering representation of something that is to be built It can be traced to a customer’s requirements.
Sommerville, Mejia-Alvarez, 2009Software Engineering, Slide 1 Software Design u Deriving a solution which satisfies software requirements.
Design engineering Vilnius The goal of design engineering is to produce a model that exhibits: firmness – a program should not have bugs that inhibit.
Software Design Deriving a solution which satisfies software requirements.
Software Design Process A solution to satisfy the requirements ◦ Design process and methods ◦ Design strategies including object-oriented design and functional.
Drexel University CS 451 Software Engineering Winter Yuanfang Cai Room 104, University Crossings
1 Software Design Overview Reference: Software Engineering, by Ian Sommerville, Ch. 12 & 13.
Architectural Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Design Concepts and Principles Instructor: Dr. Jerry Gao.
Software Engineering Principles. SE Principles Principles are statements describing desirable properties of the product and process.
Chapter 10 Software Engineering. Understand the software life cycle. Describe the development process models. Understand the concept of modularity in.
CS251 – Software Engineering Lecture 9: Software Design Slides by Mohammad El-Ramly, PhD
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
Dr D. Greer, Queens University Belfast )Chapter Six 1 Software Engineering Chapter Six Software Design Quality Learning Outcomes.
The Software Development Life Cycle: An Overview
©Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements.
SOFTWARE DESIGN & SOFTWARE ENGINEERING Software design is a process in which data, program structure, interface and their details are represented by well.
Design Engineering 1. Analysis  Design 2 Characteristics of good design 3 The design must implement all of the explicit requirements contained in the.
Engineering, 7th edition. Chapter 8 Slide 1 System models.
Design Concepts ch-8
Object-Orientated Analysis, Design and Programming
Unit - 3 OBJECT ORIENTED DESIGN PROCESS AND AXIOMS
7. Modular and structured design
CompSci 280 S Introduction to Software Development
CompSci 280 S Introduction to Software Development
Coupling and Cohesion Rajni Bhalla.
Software Engineering Lecture 4 System Modeling The Analysis Stage.
Software Design Principles
Coupling and Cohesion 1.
IS301 – Software Engineering Dept of Computer Information Systems
System Design and Modeling
Lecture 9- Design Concepts and Principles
Software Design Mr. Manoj Kumar Kar.
Part 3 Design What does design mean in different fields?
Abstract descriptions of systems whose requirements are being analysed
Software Design AITI GP John Paul Vergara.
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
Improving the Design “Can the design be better?”
CS223: Software Engineering
Object-Oriented Design
Software Design CMSC 345, Version 1/11.
Architectural Design.
Lecture 9- Design Concepts and Principles
Chapter 13 Quality Management
Chapter 5 Architectural Design.
Programming Logic and Design Fourth Edition, Comprehensive
An Introduction to Software Architecture
Software Design Methodologies and Testing
Chapter 5 Architectural Design.
Software Engineering Software Design.
DESIGN CONCEPTS AND PRINCIPLES
Presentation transcript:

which satisfies software requirements Software Design Deriving a solution which satisfies software requirements Source & Courtesy: Sommerville, Mejia - Alvarez

Objectives To introduce the process of software design To describe the different stages in this design process To show how object-oriented and functional design strategies are complementary To discuss some design quality attributes

Programmer’s Approach to Software Engineering Skip requirements engineering and design phases; start writing code

Why this programmer’s approach? Design is a waste of time We need to show something to the customer real quick We are judged by the amount of LOC/month We expect or know that the schedule is too tight

Design of small and large systems Extraida desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).

This is a simple software system! What is the Problem? This is a simple software system!

The Usual Tool: Design Abstraction We have to do better!

Architectural Abstraction

What is not Design Design is not programming. Design is not modeling. Modeling is part of the architectural design. Design is not part of requirements. Where requirements finishes and where design starts ?. Requirements = What the system is supposed to do. Design = How the system is built.

What is Design (or Architecture?) A high-level model of a software system Describes the structure, functionality and characteristics of the software system. Understandable to many stakeholders Allows evaluation of the system’s properties before it is built Provides well understood tools and techniques for constructing the thing from its blueprint A software system’s blueprint Its components Their interactions Their interconnections Which aspects of a software system are architecturally relevant?

What is Design (or Architecture?) How should they be represented most effectively to enable stakeholders to understand, reason, and communicate about a system before it is built? What tools and techniques are useful for implementing an architecture in a manner that preserves its properties? We design the software but we must consider the hardware (and the environment). Design must reflect requirements, and we must be able to relate each requirements with parts of the design. How can we include non-functional requirements into the design?

Stages of design Problem understanding Identify one or more solutions Look at the problem from different angles to discover the design requirements Identify one or more solutions Evaluate possible solutions and choose the most appropriate depending on the designer's experience and available resources Describe solution abstractions Use graphical, formal or other descriptive notations to describe the components of the design Repeat process for each identified abstraction until the design is expressed in primitive terms

From informal to formal design

The design process The system should be described at several different levels of abstraction Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary

Phases in the design process

Design phases Architectural design Identify sub-systems Abstract specification Specify sub-systems Interface design Describe sub-system interfaces Component design Decompose sub-systems into components Data structure design Design data structures to hold problem data Algorithm design Design algorithms for problem functions

From Requirements to Architecture From problem definition to requirements specification Determine exactly what the customer and user want Specifies what the software product is to do From requirements specification to architecture How do we plan to build (design) the system ? Decompose software into modules with interfaces Specify high-level behavior, interactions, and non-functional properties Consider key tradeoffs Schedule vs. Budget Cost vs. Robustness Fault Tolerance vs. Size Security vs. Speed Maintain a record of design decisions and traceability Specifies how the software product is to do its tasks (from design to programming).

Architectural design An early stage of the system design process. Represents the link between specification and design processes. Where do we finish requirements and start design ?. Often carried out in parallel with some specification activities. It involves identifying major system components and their communications.

Advantages of explicit architecture From Requirements to Design Stakeholder communication Architecture may be used as a focus of discussion by system stakeholders. System analysis Means that analysis of whether the system can meet its non-functional requirements is possible. Large-scale reuse The architecture may be reusable across a range of systems. From Design to Programming ,Testing & Mantenaince.

Architecture and system characteristics How the system must be designed to achieve: Performance Security Safety Reliability Availability Maintainability Quality

Architectural design process System structuring The system is decomposed into several principal sub-systems and communications between these sub-systems are identified Control modelling A model of the control relationships between the different parts of the system is established Modular decomposition The identified sub-systems are decomposed into modules

Design quality Design quality is an elusive concept. Quality depends on specific organisational priorities A 'good' design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc. The attributes discussed here are concerned with the maintainability of the design Quality characteristics are equally applicable to function-oriented and object-oriented designs

Design principles Abstraction Modularity, coupling and cohesion Information hiding Limit complexity Hierarchical structure Understandability Adaptability

Abstraction procedural abstraction: natural consequence of stepwise refinement: name of procedure denotes sequence of actions abstraction subproblems time

application-oriented Abstraction data abstraction: aimed at finding a hierarchy in the data application-oriented data structures simpler data structure general data structures

Modularity structural criteria which tell us something about individual modules and their interconnections cohesion and coupling cohesion: the glue that keeps a module together coupling: the strength of the connection between modules

Cohesion A measure of how well a component 'fits together' A component should implement a single logical entity or function Cohesion is a desirable design component attribute as when a change has to be made, it is localised in a single cohesive component Various levels of cohesion have been identified

Cohesion levels Coincidental cohesion (weak) Parts of a component are simply bundled together Logical association (weak) Components which perform similar functions are grouped Temporal cohesion (weak) Components which are activated at the same time are grouped Procedural cohesion (weak) The elements in a component make up a single control sequence

Cohesion levels Communicational cohesion (medium) All the elements of a component operate on the same input or produce the same output Sequential cohesion (medium) The output for one part of a component is the input to another part Functional cohesion (strong) Each part of a component is necessary for the execution of a single function Object cohesion (strong) Each operation provides functionality which allows object attributes to be modified or inspected

Cohesion as a design attribute Not well-defined. Often difficult to classify cohesion Inheriting attributes from super-classes weakens cohesion To understand a component, the super-classes as well as the component class must be examined Object class browsers assist with this process

Coupling A measure of the strength of the inter-connections between system components Loose coupling means component changes are unlikely to affect other components Shared variables or control information exchange lead to tight coupling Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing 28

Tight coupling

Loose coupling

Coupling and inheritance Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes. Such changes must be carefully controlled

Information hiding each module has a secret design involves a series of decision: for each such decision, wonder who needs to know and who can be kept in the dark information hiding is strongly related to abstraction: if you hide something, the user may abstract from that fact coupling: the secret decreases coupling between a module and its environment cohesion: the secret is what binds the parts of the module together

Complexity measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …) use these numbers as a criterion to assess a design, or to guide the design interpretation: higher value  higher complexity  more effort required (= worse design) two kinds: intra-modular: inside one module inter-modular: between modules

Top-down design In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process

Hierarchical design structure

Understandability Related to several component characteristics Cohesion. Can the component be understood on its own? Naming. Are meaningful names used? Documentation. Is the design well-documented? Complexity. Are complex algorithms used? Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand Most design quality metrics are oriented towards complexity measurement. They are of limited use

Adaptability A design is adaptable if: Its components are loosely coupled It is well-documented and the documentation is up to date There is an obvious correspondence between design levels (design visibility) Each component is a self-contained entity (tightly cohesive) To adapt a design, it must be possible to trace the links between design components so that change consequences can be analysed

Design traceability

Key points Design is a creative process Design activities include architectural design, system specification, component design, data structure design and algorithm design

Thanks…