Component-Level Design
|
|
- Ross Brown
- 6 years ago
- Views:
Transcription
1 Component-Level Design Minsoo Ryu Hanyang University
2 Contents 1. Design Model 2. Fundamental Design Concepts 3. Component-Level Design 4. Object-Oriented Design Techniques 2 2
3 Data/class design Four Design Models Transforms analysis models into design realizations and the requisite data structures required to implement the software Architectural design Defines the relationship between major structural elements of the software Interfaces design Describes how the software communicates with systems that interoperate within it, and with humans who use it Component-level design Transforms structural elements of the software architecture into a procedural description of software components 3 3
4 Three Design Quality Characteristics The design must implement all of the explicit requirements contained in the analysis model, and it must accommodate all of the implicit requirements desired by the customer The design must be a readable, understandable guide for those who generate code and for those who test and subsequently support the software The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective 4 4
5 Contents 1. Design Model 2. Fundamental Design Concepts 3. Component-Level Design 4. Object-Oriented Design Techniques 5 5
6 Fundamental Design Concepts Abstraction Modularity Information Hiding Functional independence Refinement Refactoring Architecture and Patterns 6 6
7 Abstraction Abstraction is one of the fundamental ways that we as humans cope with complexity, by Grady Booch Two types of abstraction Data abstraction Procedural abstraction 7 7
8 Data Abstraction door manufacturer model number type swing direction inserts lights type number weight opening mechanism implemented as a data structure 8 8
9 Procedural Abstraction open details of enter algorithm implemented with a "knowledge" of the object that is associated with enter 9 9
10 Modularity Modularity is the single attribute of software that allows a program to be intellectually manageable, by G. Meyers Software can be divided into separately named and addressable components, often called modules, that are integrated to satisfy problem requirements Consider two problems, p1 and p2 If the perceived complexity of two problems when they are combined is often greater than the sum of the perceived complexity when each is taken separately This leads to a divide and conquer strategy 10 10
11 Modularity What is the "right" number of modules for a specific software design? cost of software module development cost module integration cost optimal number of modules number of modules 11 11
12 Information Hiding Modules should be specified and designed so that information (algorithms and data) contained within a module is inaccessible to other modules that have no need for such information Hiding implies that effective modularity can be achieved by defining a set of independent modules that communicate with one another only that information necessary to achieve software function Abstraction helps to define the procedural (or informational) entities that make up the software 12 12
13 Information Hiding clients module controlled interface "secret" algorithm data structure details of external interface resource allocation policy a specific design decision 13 13
14 Functional Independence The functional independence is a direct outgrowth of modularity and the concepts of abstraction and information hiding Independent modules are easier to maintain (and test) because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable modules are possible 14 14
15 Functional Independence Independence is assessed using two criteria Cohesion is an indication of the relative functional strength of a module A cohesive module consists of parts that fit together well and form a united whole A cohesive module should (ideally) do just one thing Coupling is an indication of the relative interdependence among modules 15 15
16 Cohesion Cohesion implies that a component or class encapsulates only attributes and operations that are closely related to one another and to the class or component itself Functional (exhibited primarily by operations) This type of cohesion occurs when a module performs one and only one computation Communicational All operations that access the same data are defined within one class Temporal Operations that are performed to reflect a specific behavior or state, e.g., an operation performed at start-up or all operations performed when an error is detected 16 16
17 Coupling Coupling is a qualitative measure of the degree to which classes are connected to one another As classes become more interdependent, coupling increases An important objective in component-level design is to keep coupling as low as possible Content coupling Occurs when one component modifies data that is internal to another component (This violates information hiding) Common coupling Occurs when a number of components all make use of a global variable Although this sometimes necessary, common coupling can lead to uncontrolled error propagation and unforeseen side effects when changes are made Control coupling Occurs when operation A() invokes operation B() and passes a control flag to B 17 17
18 Refinement Step-wise refinement is a top-down design strategy, by Niklaus Wirth Abstraction and refinement are complementary concepts Abstraction enables a designer to specify procedure and data and yet suppress low-level details Refinement helps the designer to reveal low-level details as design progresses 18 18
19 Stepwise Refinement open walk to door; reach for knob; open door; walk through; close door. repeat until door opens turn knob clockwise; if knob doesn't turn, then take key out; find correct key; insert in lock; endif pull/push door move out of way; end repeat 19 19
20 Refactoring "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code [design] yet improves its internal structure, by Fowler When software is refactored, the existing design is examined for redundancy unused design elements inefficient or unnecessary algorithms poorly constructed or inappropriate data structures or any other design failure that can be corrected to yield a better design 20 20
21 Contents 1. Design Model 2. Fundamental Design Concepts 3. Component-Level Design 4. Object-Oriented Design Techniques 21 21
22 Component-Level Design Component-level design occurs after the first iteration of architectural design has been completed At this stage, the overall data and program structure of the software has been established The intent is to define the data structures, algorithms, interface characteristics, and communication mechanisms allocated to each software component 22 22
23 What is a Component? A component is a modular building block for computer software OMG Unified Modeling Language Specification defines a component as a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces The true meaning of the term component will differ depending on the point of view of the software engineer who use it 23 23
24 The Conventional View of Component-Level Design A component is a functional element of a program that incorporates processing logic, the internal data structures that are required to implement the processing logic, and an interface that enables the component to be invoked and data to be passed to it A conventional component is also called a module Three roles A control component that coordinates the invocation of all other problem domain components A problem domain component that implements a complete or partial function that is required by the customer An infrastructure component that is responsible for functions that support the processing required in the problem domain 24 24
25 Conducting Component-Level Design 1. Identify all design components problem domain infrastructure domain 2. Elaborate all design components communications, interfaces, data structures, operations 3. Describe persistent data sources and identify relevant components databases and/or files required components 4. Develop and elaborate behavioral representations data-flow models or state machine models 5. Elaborate deployment specific HW/SW environments locations of components 25 25
26 Step 1: Identify All Design Components Step 1.1 Identify design components from the problem domain Use architectural components and refine them Step 1.2 Identify design components from the infrastructure domain GUI-related components, OS-related components, etc 26 26
27 Step 2: Elaborate Design Components Apply the design concepts and techniques we have learned Step 2.1 Specify messages that are passed between design components (message name, content, and properties) Step 2.2 Identify interfaces for each component (interface name and properties) Step 2.3 Identify data structures and data types (variables and complex data structures) Step 2.4 Describe processing flow within each operation (flow chart or UML activity diagram) Specify the parameters and their types for each operation 27 27
28 Communications and Messages :ProductionJob 1: buildjob ( WOnumber ) 2: submitjob ( WOnumber ) :WorkOrder :JobQueue 28 28
29 Interfaces computejob Print Jo b initiatejob WorkOrder getjobdescriiption appropriate attributes buildworkorder () buildjob <<interface>> initiatejob Pro d uct io njo b passjobtoproduction() JobQueue submitjob appropriate attributes checkpriority () 29 29
30 Processing Flow validate attributes input accesspaperdb(weight) returns basecostperpage papercostperpage = basecostperpage size = B papercostperpage = papercostperpage * 1.2 size = C papercostperpage = papercostperpage * 1.4 size = D papercostperpage = papercostperpage * 1.6 color is custom papercostperpage = papercostperpage * color is standard returns ( papercostperpage ) 30 30
31 Step 3: Describe Persistent Data Sources and Identify Relevant Components In most cases, persistent data stores are initially specified as part of architectural design Step 3.1 Provide additional detail about the structure and organization of the persistent data stores Step 3.2 Identify design components that are required to manage them 31 31
32 Step 4: Develop and Elaborate Behavioral Representations In many cases, state machine models are used to represent the behavior of entire system and/or of certain component Step 4.1 Identify and draw states, events, transitions, and actions for the overall system Step 4.2 Identify and draw states, events, transitions, and actions for individual component 32 32
33 Statechart Diagram behavior within the state buildingjobdata datainputincomplete buildingjobdat a ent ry/ readjobdat a () exit / displayjobdat a () do/ checkconsist ency() include/ dat ainput datainputcompleted [all data items consistent]/displayuseroptions comput ingjobcost ent ry/ comput ejob exit / save t ot aljobcost jobcostaccepted [customer is authorized]/ getelectronicsignature formingjob entry/ buildjob exit / save WOnumber do/ submittingjob entry/ submitjob exit / init iat ejob do/ place on JobQueue jobsubmitted[ all au t h o rizat io n s acq u ired ] / printworkorder 33 33
34 Step 5: Elaborate Deployment In many cases, state machine models are used to represent the behavior of entire system and/or of certain component Step 5.1 Identify the computing environment that will house design components Step 5.2 Specify the location of each component Step 5.3 Describe specific hardware and/or software environments 34 34
35 Contents 1. Design Model 2. Fundamental Design Concepts 3. Component-Level Design 4. Object-Oriented Design Techniques 35 35
36 Object-Oriented Design When an object-oriented approach is chosen, component-level design focuses on the elaboration of; analysis classes (problem domain classes) the definition and refinement of infrastructure classes 36 36
37 Basic Design Principles Four basic design principles are applicable to OO component-level design The Open-Closed Principle (OCP) The Liskov Substitution Principle (LSP) Dependency Inversion Principle (DIP) The Interface Segregation Principle (ISP) The underlying motivation is To create designs that are more amenable to change To reduce the propagation 37 37
38 The Open-Closed Principle (OCP) A module should be open for extension but closed for modification The designer should specify the component in a way that allows it to be extended without the need to make internal modifications to the component itself To accomplish this, the designer creates abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself Design and write a module in a fashion that adding new functionality would involve minimal changes to existing code 38 38
39 Example of OCP Violation 39 39
40 A Possible Solution The key mechanisms for OCP are abstraction (inheritance) and polymorphism! * Polymorphism in OO allows the exact behavior to be determined at run-time (late binding) 40 40
41 The Liskov Substitution Principle (LSP) Subclasses should be substituable for their base classes If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program Also known as Design by Contract A "client" and a "supplier" agree on a "contract The Liskov Substitution Principle is an important feature of all programs that conform to the Open- Closed Principle It is only when inheriting classes should not perform any actions that will invalidate the assumptions made by the base class 41 41
42 Example of LSP Violation Rectangle Square Assertion error! The area of rectangle would be
43 Is a Square a Rectangle? To understand the subtleties of extendable class design, we must address the question "Is a Square a specialization of a Rectangle?" At first glance this seems valid since mathematically a square IS A rectangle However, this class hierarchy fails to adhere to the Liskov Substitution principle because the behavior of a Square differs from the behavior of a Rectangle The subclass may only expand the behavior of the base class How to fix this problem? Square and Rectangle both inherit from Shape, or Square s Set_Width should not alter the height The base class is the abstraction of subclass, hence, the subclass should not change the abstract behavior of the base class 43 43
44 LSP and Design by Contract...when redefining a routine [in a derivative], you may only replace its precondition by a weaker one, and its postcondition by a stronger one In other words, when using an object through its base class interface, the user knows only the preconditions and postconditions of the base class Thus, derived objects must not expect such users to obey preconditions that are stronger then those required by the base class That is, they must accept anything that the base class could accept 44 44
45 Dependency Inversion Principle (DIP) Depend on abstractions. Do not depend on concretions High level modules should not depend upon low level modules Both should depend upon abstractions Abstractions should not depend upon details Details should depend upon abstractions 45 45
46 Example of DIP The Copy module calls the other two in a loop The body of that loop calls the Read Keyboard module to fetch a character from the keyboard, it then sends that character to the Write Printer module which prints the character The two low level modules are nicely reusable However the Copy module is not reusable in any context which does not involve a keyboard or a printer 46 46
47 Example of DIP Consider a new program that copies to a disk file We could add an if statement to its policy and have it select between the Write Printer module and the Write Disk module depending upon some kind of flag Consider the implications of high level modules that depend upon low level modules Yet, when these modules depend upon the lower level modules, then changes to the lower level modules can have direct effects upon them; and can force them to change Moreover, it is high level modules that we want to be able to reuse 47 47
48 A Possible Solution The dependency structure of a well designed object oriented program is inverted with respect to the dependency structure that normally results from traditional procedural methods A solution is to have a Copy class which contains an abstract Reader class and an abstract Writer class 48 48
49 The Interface Segregation Principle (ISP) Clients should not be forced to depend upon interfaces that they do not use This principle deals with the disadvantages of fat interfaces Classes that have fat interfaces are classes whose interfaces are not cohesive In other words, the interfaces of the class can be broken up into groups of member functions Each group serves a different set of clients Thus some clients use one group of member functions, and other clients use the other groups 49 49
50 Example of ISP Violation 50 50
51 A Possible Solution 51 51
Moonzoo Kim CS Division of EECS Dept. CS350 Intro. to SE Spring
Chapter 11 Component-Level Design Moonzoo Kim CS Division of EECS Dept. KAIST moonzoo@cs.kaist.ac.kr http://pswlab.kaist.ac.kr/courses/cs350-07 Spring 2008 1 Overview of Ch 11. Modeling Component-level
More informationComponent-Level Design. Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only
Chapter 14 Component-Level Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger
More informationComponent-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman. For non-profit educational use only
Chapter 10 Component-Level Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit
More informationDesign Concepts and Principles
Design Concepts and Principles Analysis to Design Data Object Description Entity- Relationship Diagram Data Flow Diagram Process Specification (PSPEC) Component level design (or) procedural design Data
More informationDesign Concepts. Slide Set to accompany. Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman
Chapter 8 Design Concepts Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For non-profit educational
More information09. Component-Level Design
09. Component-Level Design Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 What is Component OMG UML Specification defines a component as OO view a
More informationChapter 9 Design Engineering
Chapter 9 Design Engineering Moonzoo Kim CS Division of EECS Dept. KAIST 1 Roadmap of SEPA covered in CS550 Ch 1 Ch 5 1. Intro to SE 2. A Generic View of Process 3. Process Models 4. An Agile View of Process
More informationCHAPTER 9 DESIGN ENGINEERING. Overview
CHAPTER 9 DESIGN ENGINEERING Overview A software design is a meaningful engineering representation of some software product that is to be built. Designers must strive to acquire a repertoire of alternative
More informationComponent-Level Design. Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman (revised by Seung- Hoon Na) For non-profit educational use only
Chapter 14 Component-Level Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman (revised
More informationCSEB233: Fundamentals of Software Engineering. Software Design
CSEB233: Fundamentals of Software Engineering Software Design Objectives Explain set of design principles, concepts, and practices Describe five design models complete design specification: required for
More informationSE300 SWE Practices. Lecture 10B Component Design (Abstraction, Interface/Implementation, Cohesion, Coupling, Refactoring) Tuesday, March 17, 2015
SE300 SWE Practices Lecture 10B Component Design (Abstraction, Interface/Implementation, Cohesion, Coupling, Refactoring) Tuesday, March 17, 2015 Sam Siewert Synchronization with Text SEPA (Pressman) Chapter
More informationLecture 8: Chapter 8!
Lecture 8: Chapter 8! Design Concepts! Slide Set to accompany Software Engineering: A Practitioner s Approach, 7/e " by Roger S. Pressman Slides copyright 1996, 2001, 2005, 2009 by Roger S. Pressman For
More informationSoftware Engineering
Software Engineering CSC 331/631 - Spring 2018 Object-Oriented Design Principles Paul Pauca April 10 Design Principles DP1. Identify aspects of the application that vary and separate them from what stays
More informationSoftware Engineering CSC40232: SOFTWARE ENGINEERING. Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017
CSC40232: SOFTWARE ENGINEERING Guest Lecturer: Jin Guo SOLID Principles sarec.nd.edu/courses/se2017 Department of Computer Science and Engineering http://www.kirkk.com/modularity/2009/12/solid-principles-of-class-design/
More informationPrinciples of Object-Oriented Design
Principles of Object-Oriented Design 1 The Object-Oriented... Hype What are object-oriented (OO) methods? OO methods provide a set of techniques for analysing, decomposing, and modularising software system
More informationDesign Principles: Part 2
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &
More informationOutline. Design Principles: Part 2. e.g. Rectangles and Squares. The Liskov Substitution Principle (LSP) ENGI 5895: Software Design.
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation
More informationIntro to: Design Principles
Intro to: Design Principles Pragmatic Programmer: Eliminate Effects Between Unrelated Things design components that are: self-contained, independent, and have a single, well-defined purpose Software Design
More informationDesign Principles: Part 2
Liskov Substitution Principle (LSP) Dependency-Inversion Principle (DIP) Interface-Segregation Principle (ISP) Design Principles: Part 2 ENGI 5895: Software Design Andrew Vardy Faculty of Engineering &
More informationCS485/540 Software Engineering Architecture and Component Design (Chs. 9,10)
CS485/540 Software Engineering Architecture and Component Design (Chs. 9,10) Cengiz Günay Dept. Math & CS, Emory University Fall 2013 Some slides courtesy of Joan Smith, Roger Pressman, Ian Sommerville,
More informationSummary of the course lectures
Summary of the course lectures 1 Components and Interfaces Components: Compile-time: Packages, Classes, Methods, Run-time: Objects, Invocations, Interfaces: What the client needs to know: Syntactic and
More informationIntroduction to Software Engineering
Introduction to Software Engineering (CS350) Lecture 09 Jongmoon Baik Design Concept 2 Design Mitch Kapor, the creator of Lotus 1-2-3, presented a software design manifesto in Dr. Dobbs Journal. He said:
More informationIngegneria del Software Corso di Laurea in Informatica per il Management. Software quality and Object Oriented Principles
Ingegneria del Software Corso di Laurea in Informatica per il Management Software quality and Object Oriented Principles Davide Rossi Dipartimento di Informatica Università di Bologna Design goal The goal
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationSOLID Principles. Equuleus Technologies. Optional Subheading October 19, 2016
SOLID Principles Optional Subheading October 19, 2016 Why SOLID Principles? The traits of well designed software are as follows Maintainability - The ease with which a software system or component can
More informationCHAPTER 5: PRINCIPLES OF DETAILED DESIGN
CHAPTER 5: PRINCIPLES OF DETAILED DESIGN SESSION II: STRUCTURAL AND BEHAVIORAL DESIGN OF COMPONENTS Software Engineering Design: Theory and Practice by Carlos E. Otero Slides copyright 2012 by Carlos E.
More informationOpen Closed Principle (OCP)
Open Closed Principle (OCP) Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ SOLID Class Design Principles
More information!"#$%&'()*+,-*,--)./00#'1)2)345"645"%()
!"#$%&'()*+,-*,--)./00#'1)2)345"645"%() Chapter 9!! Architectural Design! Slide Set to accompany Software Engineering: A Practitionerʼs Approach, 7/e # by Roger S. Pressman Slides copyright 1996, 2001,
More information17.11 Bean Rules persistent
17.10 Java Beans Java beans are a framework for creating components in Java. AWT and Swing packages are built within this framework Made to fit in with graphic development environments such as Jbuilder
More informationCSC207H: Software Design SOLID. CSC207 Winter 2018
SOLID CSC207 Winter 2018 1 SOLID Principles of Object-Oriented Design How do we make decisions about what is better and what is worse design? Principles to aim for instead of rules. e.g. there is no maximum
More informationOO Class Design Principles
3.3 Class Design Principles Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) a.k.a. Design by Contract Dependency Inversion Principle (DIP) Interface
More informationObject-Oriented Design
Object-Oriented Design Lecturer: Raman Ramsin Lecture 15: Object-Oriented Principles 1 Open Closed Principle (OCP) Classes should be open for extension but closed for modification. OCP states that we should
More informationCOURSE 2 DESIGN PATTERNS
COURSE 2 DESIGN PATTERNS CONTENT Fundamental principles of OOP Encapsulation Inheritance Abstractisation Polymorphism [Exception Handling] Fundamental Patterns Inheritance Delegation Interface Abstract
More informationLecture: Modular Design
Software Engineering Lecture: Modular Design Thomas Fritz Many thanks to Philippe Beaudoin, Gail Murphy, David Shepherd, Neil Ernst and Meghan Allen Reading! For next lecture: (all required) Composite
More informationUNIT III. Software Design
UNIT III Software Design Design Specification Models Data design - created by transforming the analysis information model (data dictionary and ERD) into data structures required to implement the software
More informationLearning Objectives. C++ For Artists 2003 Rick Miller All Rights Reserved xli
Identify and overcome the difficulties encountered by students when learning how to program List and explain the software development roles played by students List and explain the phases of the tight spiral
More informationSlides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only
Chapter 12 Design Concepts Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger S.
More informationUNIT III DESIGN CONCEPTS AND PRINCIPLES
UNIT III DESIGN CONCEPTS AND PRINCIPLES Design process and concepts modular design design heuristic design model and document. Architectural design software architecture data design architectural design
More informationSingle Responsibility Principle (SRP)
Single Responsibility Principle (SRP) Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ SOLID Class Design
More informationObject- Oriented Design with UML and Java Part I: Fundamentals
Object- Oriented Design with UML and Java Part I: Fundamentals University of Colorado 1999-2002 CSCI-4448 - Object-Oriented Programming and Design These notes as free PDF files: http://www.softwarefederation.com/cs4448.html
More informationCPSC 410? Advanced Software Engineering Mid-term Examination (Term I ) SOLUTION Instructor: Gail Murphy
CPSC 410? Advanced Software Engineering Mid-term Examination (Term I 2001-2002) SOLUTION Instructor: Gail Murphy Do NOT start until you are informed you can start! This examination has 7 questions. The
More informationS.O.L.I.D: Software Engineering Principles
DCC / ICEx / UFMG S.O.L.I.D: Software Engineering Principles Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo S.O.L.I.D Principles These principles intend to create systems that are easier to maintain
More informationGRASP Design Patterns A.A. 2018/2019
GRASP Design Patterns A.A. 2018/2019 Objectives Introducing design patterns Introduzione ai design pattern Designing objects and responsibilities GRASP design patterns A long corridor A passage room Does
More informationConception Orientée Objets. Programmation SOLID
Conception Orientée Objets Programmation SOLID Frédéric Mallet http://deptinfo.unice.fr/~fmallet/ F. Mallet SOLID 1 Objectives Introduce some principles to guide the design Single responsibility Open Closed
More informationObject-Oriented Design
Object-Oriented Design Department of Computer Engineering Lecture 12: Object-Oriented Principles Sharif University of Technology 1 Open Closed Principle (OCP) Classes should be open for extension but closed
More informationObject-Oriented Concepts and Design Principles
Object-Oriented Concepts and Design Principles Signature Specifying an object operation or method involves declaring its name, the objects it takes as parameters and its return value. Known as an operation
More informationChapter 8: Class and Method Design
Chapter 8: Class and Method Design Objectives Become familiar with coupling, cohesion, and connascence. Be able to specify, restructure, and optimize object designs. Be able to identify the reuse of predefined
More informationSOLID: Principles of OOD
SOLID: Principles of OOD CS480 Software Engineering http://cs480.yusun.io February 18, 2015 Yu Sun, Ph.D. http://yusun.io yusun@cpp.edu Software Nature Software Entropy Software tends to degrade / decay
More informationLethbridge/Laganière 2005 Chapter 9: Architecting and designing software 6
Trying to deal with something big all at once is normally much harder than dealing with a series of smaller things Separate people can work on each part. An individual software engineer can specialize.
More informationSOFTWARE ENGINEERING SOFTWARE DESIGN. Saulius Ragaišis.
SOFTWARE ENGINEERING SOFTWARE DESIGN Saulius Ragaišis saulius.ragaisis@mif.vu.lt CSC2008 SE Software Design Learning Objectives: Discuss the properties of good software design including the nature and
More informationChapter 1: Programming Principles
Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key
More informationAbstraction. Design fundamentals in OO Systems. Fundamental Software Development Principles
Abstraction Design fundamentals in OO Systems Tool for abstraction: object Object structure: properties and values for those properties operations to query and update those properties We refer to the collection
More informationCMPS 115 Winter 04. Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD <break> Design Patterns
CMPS 115 Winter 04 Class #10 (2004/02/05) Changes/Review Programming Paradigms Principles of OOD Design Patterns Changes & Lecture 9 Takeaway Changes/Notices 2/26 may be guest after all, on design-with-frameworks
More informationUNIT II Requirements Analysis and Specification & Software Design
UNIT II Requirements Analysis and Specification & Software Design Requirements Analysis and Specification Many projects fail: because they start implementing the system: without determining whether they
More informationLiskov Substitution Principle
Liskov Substitution Principle Produced by: Eamonn de Leastar (edeleastar@wit.ie) Dr. Siobhán Drohan (sdrohan@wit.ie) Department of Computing and Mathematics http://www.wit.ie/ SOLID Class Design Principles
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationBruno Bossola SOLID Design Principles
Bruno Bossola SOLID Design Principles About me C Developer since 1988 Java developer since 1996 XP Coach during 2000 2001 Lead coordinator and co founder of JUG Torino in 2001 Sun Java Champion since 2005
More information1 Executive Overview The Benefits and Objectives of BPDM
1 Executive Overview The Benefits and Objectives of BPDM This is an excerpt from the Final Submission BPDM document posted to OMG members on November 13 th 2006. The full version of the specification will
More informationChapter 5 Object-Oriented Programming
Chapter 5 Object-Oriented Programming Develop code that implements tight encapsulation, loose coupling, and high cohesion Develop code that demonstrates the use of polymorphism Develop code that declares
More informationTopic : Object Oriented Design Principles
Topic : Object Oriented Design Principles Software Engineering Faculty of Computing Universiti Teknologi Malaysia Objectives Describe the differences between requirements activities and design activities
More informationThe Object Oriented Paradigm
The Object Oriented Paradigm Joseph Spring 7COM1023 Programming Paradigms 1 Discussion The OO Paradigm Procedural Abstraction Abstract Data Types Constructors, Methods, Accessors and Mutators Coupling
More informationS.O.L.I.D. Principles of
S.O.L.I.D. Principles of Object-Oriented Class Design Fifteen Years Later. Copyright 1998-2010 by Object Mentor, Inc Portions of this material are Copyright 1998, by Addison Wesley Longman,Inc. and have
More informationChapter 1: Principles of Programming and Software Engineering
Chapter 1: Principles of Programming and Software Engineering Data Abstraction & Problem Solving with C++ Fifth Edition by Frank M. Carrano Software Engineering and Object-Oriented Design Coding without
More informationDesign Engineering. Overview
Design Engineering Overview What is software design? How to do it? Principles, concepts, and practices High-level design Low-level design N. Meng, B. Ryder 2 1 Design Engineering The process of making
More informationPrincípy tvorby softvéru Dizajnové princípy
Robert Luko ka lukotka@dcs.fmph.uniba.sk www.dcs.fmph.uniba.sk/~lukotka M-255 Analýza a dizajn - úrovne Architektúra Vysokoúrov ový analytický model... Nízkoúrov ový analytický model Implementa ný model
More informationCSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich
CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and
More informationLast Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns
Last Time: Object Design Comp435 Object-Oriented Design Week 7 Computer Science PSU HBG The main idea RDD: Responsibility-Driven Design Identify responsibilities Assign them to classes and objects Responsibilities
More informationIndex. Index. More information. block statements 66 y 107 Boolean 107 break 55, 68 built-in types 107
A abbreviations 17 abstract class 105 abstract data types 105 abstract method 105 abstract types 105 abstraction 92, 105 access level 37 package 114 private 115 protected 115 public 115 accessors 24, 105
More informationCAS 703 Software Design
Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Other 1 2 3 4 Other Principle of Least Privilege Principle of Fail-Safe Defaults Principle of
More informationMinsoo Ryu. College of Information and Communications Hanyang University.
Software Reuse and Component-Based Software Engineering Minsoo Ryu College of Information and Communications Hanyang University msryu@hanyang.ac.kr Software Reuse Contents Components CBSE (Component-Based
More informationChapter 9 Design Engineering
Software Engineering: A Practitioner s s Approach, 6/e Chapter 9 Design Engineering copyright 1996, 2001, 2005 R.S. Pressman & Associates, Inc. For University Use Only May be reproduced ONLY for student
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationIncremental development A.Y. 2018/2019
Incremental development A.Y. 2018/2019 Incremental development Interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with
More informationAOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz
AOSA - Betriebssystemkomponenten und der Aspektmoderatoransatz Results obtained by researchers in the aspect-oriented programming are promoting the aim to export these ideas to whole software development
More informationFrom Module To Objects
From Module To Objects It is very difficult to maintain a large monolithic block of code The solution is to divide the code into smaller pieces, called modules What is a Module? A small and manageable
More informationChapter 10 Classes Continued. Fundamentals of Java
Chapter 10 Classes Continued Objectives Know when it is appropriate to include class (static) variables and methods in a class. Understand the role of Java interfaces in a software system and define an
More informationPlan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?
Plan Design principles: laughing in the face of change Perdita Stevens School of Informatics University of Edinburgh What are we trying to achieve? Review: Design principles you know from Inf2C-SE Going
More informationOO Design Principles
OO Design Principles Software Architecture VO (706.706) Roman Kern Institute for Interactive Systems and Data Science, TU Graz 2018-10-10 Roman Kern (ISDS, TU Graz) OO Design Principles 2018-10-10 1 /
More informationObject-Oriented Design II
Object-Oriented Design II SWEN-261 Introduction to Software Engineering Department of Software Engineering Rochester Institute of Technology Controller Pure fabrication Open/close Polymorphism Liskov substitution
More informationLab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester
Lab Manual Object Oriented Analysis And Design TE(Computer) VI semester Index Sr. No. Title of Programming Assignment Page No. 1 2 3 4 5 6 7 8 9 10 Study of Use Case Diagram Study of Activity Diagram Study
More informationCS 307: Software Engineering. Lecture 10: Software Design and Architecture
CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra 2017 Dr. Jeffrey A. Turkstra 1 Announcements Discuss your product backlog in person or via email by Today Office
More informationSoftware Development. Modular Design and Algorithm Analysis
Software Development Modular Design and Algorithm Analysis Precondition and Postcondition To create a good algorithm, a programmer must be able to analyse a precondition (starting state) and a postcondition
More informationObject Oriented Software Design - I
Object Oriented Software Design - I Object Oriented Design Principles Giuseppe Lipari http://retis.sssup.it/~lipari Scuola Superiore Sant Anna Pisa October 28, 2011 G. Lipari (Scuola Superiore Sant Anna)
More informationLecture 13: Object orientation. Object oriented programming. Introduction. Object oriented programming. OO and ADT:s. Introduction
Lecture 13: Object orientation Object oriented programming Introduction, types of OO languages Key concepts: Encapsulation, Inheritance, Dynamic binding & polymorphism Other design issues Smalltalk OO
More informationCHAPTER 5 GENERAL OOP CONCEPTS
CHAPTER 5 GENERAL OOP CONCEPTS EVOLUTION OF SOFTWARE A PROGRAMMING LANGUAGE SHOULD SERVE 2 RELATED PURPOSES : 1. It should provide a vehicle for programmer to specify actions to be executed. 2. It should
More informationStudy of Component Based Software Engineering
Study of Based Software Ishita Verma House No.4, Village Dayalpur Karawal Nagar Road Delhi-110094, India ish.v.16@gmail.com Abstract based engineering is an approach of development that emphasizes the
More informationPC204. Lecture 5 Programming Methodologies. Copyright 2000 by Conrad Huang and the Regents of the University of California. All rights reserved.
PC204 Lecture 5 Programming Methodologies Copyright 2000 by Conrad Huang and the Regents of the University of California. All rights reserved. Programming Paradigms Software Engineering Exploratory Programming
More informationAgile Software Development
Agile Software Development Principles, Patterns, and Practices Robert Cecil Martin Alan Apt Series Prentice Hall Pearson Education, Inc. Upper Saddle River, New Jersey 07458 Foreword Preface About the
More informationInheritance and object compatibility
Inheritance and object compatibility Object type compatibility An instance of a subclass can be used instead of an instance of the superclass, but not the other way around Examples: reference/pointer can
More informationACRONYMS AND GLOSSARY
Appendix A ACRONYMS AND GLOSSARY SYS-ED/ COMPUTER EDUCATION TECHNIQUES, INC. 1 Acronyms Acronym 1NF 1ONF 2NF 2ONF 2ONF 3NF 3ONF API CASE CORBA CRUD DFD FLOOT IDL Java VM ODMG OMG OODBMS OOUI OQL ODBC OOCRUD
More informationUnit Wise Questions. Unit-1 Concepts
Unit Wise Questions Unit-1 Concepts Q1. What is UML? Ans. Unified Modelling Language. It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the aspects of
More informationComponent-based Architecture Buy, don t build Fred Broks
Component-based Architecture Buy, don t build Fred Broks 1. Why use components?... 2 2. What are software components?... 3 3. Component-based Systems: A Reality!! [SEI reference]... 4 4. Major elements
More informationTopics in Object-Oriented Design Patterns
Software design Topics in Object-Oriented Design Patterns Material mainly from the book Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides; slides originally by Spiros Mancoridis;
More informationThe Challenge. Principles of Software Design
Squircle {2 * k.radius = r.a = r.b +set_a() +resize(factor:double) Shape -position: Point = (10, 10) +area(): double +draw() +set_position(position: Point) +get_position(): Point Circle -radius: double
More informationWelcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas
Welcome to Design Patterns! For syllabus, course specifics, assignments, etc., please see Canvas What is this class about? While this class is called Design Patterns, there are many other items of critical
More informationSoftware Engineering with Objects and Components Open Issues and Course Summary
Software Engineering with Objects and Components Open Issues and Course Summary Massimo Felici Software Engineering with Objects and Components Software development process Lifecycle models and main stages
More informationArchitectural Design
Architectural Design Minsoo Ryu Hanyang University 1. Architecture 2. Architectural Styles 3. Architectural Design Contents 2 2 1. Architecture Architectural design is the initial design process of identifying
More informationArchitecture and the UML
Architecture and the UML Models, Views, and A model is a complete description of a system from a particular perspective Use Case Use Case Sequence Use Case Use Case Use Case State State Class State State
More informationCS485/540 Software Engineering Design Concepts (Ch. 8)
CS485/540 Software Engineering Design Concepts (Ch. 8) Cengiz Günay Dept. Math & CS, Emory University Fall 2013 Some slides courtesy of Joan Smith, Roger Pressman, and the Internets Günay (Emory) Design
More informationA Hierarchical Model for Object- Oriented Design Quality Assessment
A Hierarchical Model for Object- Oriented Design Quality Assessment IEEE Transactions on Software Engineering (2002) Jagdish Bansiya and Carl G. Davis 2013-08-22 Yoo Jin Lim Contents Introduction Background
More information