Implementation Goals: “map” design to clean, efficient code Document any design changes found to be useful Produce code that is correct, modular, understandable,

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Programming Paradigms and languages
Database Systems: Design, Implementation, and Management Tenth Edition
Composition CMSC 202. Code Reuse Effective software development relies on reusing existing code. Code reuse must be more than just copying code and changing.
Aspect Oriented Programming. AOP Contents 1 Overview 2 Terminology 3 The Problem 4 The Solution 4 Join point models 5 Implementation 6 Terminology Review.
Conquering Complex and Changing Systems Object-Oriented Software Engineering Chapter 7, Object Design.
Object Oriented Design An object combines data and operations on that data (object is an instance of class) data: class variables operations: methods Three.
Object-Oriented Analysis and Design
Use-case Modeling.
Conquering Complex and Changing Systems Object-Oriented Software Engineering TJSS System Design Lecture 12 Päivi Ovaska.
Liang,Introduction to Java Programming,revised by Dai-kaiyu 1 Chapter 10 Object-Oriented Modeling.
File Systems and Databases
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Implementation Goals: “map” design to clean, efficient code Document any design changes found to be useful Produce code that is correct, modular, understandable,
Feb. 23, 2004CS WPI1 CS 509 Design of Software Systems Lecture #5 Monday, Feb. 23, 2004.
Chapter 1 Principles of Programming and Software Engineering.
1 Object-Oriented Design. 2 Objectives F To become familiar with the process of program development. F To the relationship types: association, aggregation,
© 2006 Pearson Addison-Wesley. All rights reserved4-1 Chapter 4 Data Abstraction: The Walls.
Chapter 10 Classes Continued
1 ES 314 Advanced Programming Lec 2 Sept 3 Goals: Complete the discussion of problem Review of C++ Object-oriented design Arrays and pointers.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Reengineering 2003 년 12 월 2 일 최창익, 고광 원.
CS 8532: Adv. Software Eng. – Spring 2007 Dr. Hisham Haddad Tuesday Class will start momentarily. Please Stand By … CS 8532: Advanced Software.
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented Design.
REFACTORING Lecture 4. Definition Refactoring is a process of changing the internal structure of the program, not affecting its external behavior and.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 12 Object-Oriented.
1 CSC 427: Data Structures and Algorithm Analysis Fall 2011 See online syllabus (also available through BlueLine): Course goals:
SWE 316: Software Design and Architecture – Dr. Khalid Aljasser Objectives Lecture 11 : Frameworks SWE 316: Software Design and Architecture  To understand.
1 Chapter 5 Practice: A Generic View Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 9, Object Design: Specifying Interfaces.
Database Systems: Design, Implementation, and Management Ninth Edition
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
1 Java Inheritance. 2 Inheritance On the surface, inheritance is a code re-use issue. –we can extend code that is already written in a manageable manner.
07 Coding Conventions. 2 Demonstrate Developing Local Variables Describe Separating Public and Private Members during Declaration Explore Using System.exit.
CSC 211 Introduction to Design Patterns. Intro to the course Syllabus About the textbook – Read the introduction and Chapter 1 Good attendance is the.
CSE 219 Computer Science III Program Design Principles.
Low-Level Detailed Design SAD (Soft Arch Design) Mid-level Detailed Design Low-Level Detailed Design Design Finalization Design Document.
Introduction CS 3358 Data Structures. What is Computer Science? Computer Science is the study of algorithms, including their  Formal and mathematical.
Unified Modeling Language © 2002 by Dietrich and Urban1 ADVANCED DATABASE CONCEPTS Unified Modeling Language Susan D. Urban and Suzanne W. Dietrich Department.
Object Oriented Software Development
Data Abstaraction Chapter 10.
1 CSCD 326 Data Structures I Software Design. 2 The Software Life Cycle 1. Specification 2. Design 3. Risk Analysis 4. Verification 5. Coding 6. Testing.
Using UML, Patterns, and Java Object-Oriented Software Engineering Chapter 10, Mapping Models to Relational Schema.
Mapping Models to Code. We will skip most of this chapter –It deals with how to go from UML class diagrams to actual code –You should already have a pretty.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
GoodOO Programming Practice in Java © Allan C. Milne v
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Chapter 11 Object-Oriented.
Liang, Introduction to Java Programming, Sixth Edition, (c) 2007 Pearson Education, Inc. All rights reserved Object-Oriented Design.
March 1, 2004CS WPI1 CS 509 Design of Software Systems Lecture #6 Monday, March 1, 2004.
Chapter 18 Object Database Management Systems. Outline Motivation for object database management Object-oriented principles Architectures for object database.
Class Diagrams. Terms and Concepts A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships.
Introduction to Objects and Encapsulation Computer Science 4 Mr. Gerb Reference: Objective: Understand Encapsulation and abstract data types.
Exceptions Lecture 11 COMP 401, Fall /25/2014.
Chapter 2 Principles of Programming and Software Engineering.
Object Design More Design Patterns Object Constraint Language Object Design Specifying Interfaces Review Exam 2 CEN 4010 Class 18 – 11/03.
Principles of Programming. Achieving an Object-Oriented Design  Abstraction and Information Hiding  Object-Oriented Design  Functional Decomposition.
CSCE 240 – Intro to Software Engineering Lecture 3.
Principles of Programming & Software Engineering
CompSci 280 S Introduction to Software Development
Chapter 11 Object-Oriented Design
Principles of Programming and Software Engineering
CSCE 606: From Models to Implementation
Lec 3: Object-Oriented Data Modeling
CS 8532: Advanced Software Engineering
CMPE/SE 131 Software Engineering March 7 Class Meeting
Presentation transcript:

Implementation Goals: “map” design to clean, efficient code Document any design changes found to be useful Produce code that is correct, modular, understandable, modifiable Reduce errors which creep in during “transformations” (e.g., Lord of the Rings example, Ch. 10 of Bruegge & Dutoit: 5 published versions, none completely correct)) Implementation / Coding RequirementsDesignSpecsVersion 1Version 2

Guiding principles: 1. “do the simplest thing that works” 2. Make good choices (array vs linked list; bubblesort vs quicksort; separate classes vs inheritance; etc.) 3. DOCUMENT!!!!!!!—keep code and documentation consistent

Goal: produce robust software Problem: a robust procedure but may not be realistic * The word robust, when used with regard to computer software, refers to an operating system or other program that performs well not only under ordinary conditions but also under unusual conditions that stress its designers' assumptions. …operating systemprogram The Rule of Robustness in the Unix philosophy states that robustness results from transparency and simplicity. Software is transparent when a skilled programmer can examine its source code (i.e., the original version written by a human in a programming language) and soon comprehend how it works. It is simple when its operation is sufficiently uncomplicated that a programmer can visualize with little effort all of the potential situations that it might encounter. The more that programs have both of these qualities, the more robust they will be.source code Another important tactic for creating robust software is to write general code that can accommodate a wide range of situations and thereby avoid having to insert extra code into it just to handle special cases. This is because code added just to accommodate special cases is often buggier than other code, and stability problems can become particularly frequent and/or severe from the interactions among several such sections of code. accessed 07/27/2010

Types of transformations 1.model transformation 2.refactoring 3.forward engineering 4.reverse engineering

Model transformation: Simplify or optimize, e.g., --recognize that different types of events can be organized as children of an EVENT class --get rid of a redundant attribute: figure 10.2, p. 397: Address in 3 separate classes is moved to a superclass User for these 3 classes

Refactoring Change the source code to improve its readability or modifiability “pull up”: do in small incremental steps to check that behavior is appropriate Example—3 steps, check consistency, test after each: 1-“pull up” field Address to superclass (check consistency) 2-“pull up” constructor body which initializes address 3-”pull up” any associated methods which can be moved

Forward engineering: Use previously developed code to generate similar statements Example: p. 400: --design made “LeagueOwner” a subclass of “User” --in code “LeagueOwner” can be designated as a class which “extends” “User” and code can be reused, with changes in variable and method names as needed

Reverse engineering: Recreate the model for an existing system from the implementation (also common in hardware)

Principles of transformation: 1.One transformation addresses only one criterion for ONE design goal 2.A transformation must be local 3.Each transformation must be applied in isolation to other changes 4.Each transformation must be validated Q: how does this apply to coding habits?

Common transformation (“mapping”) activities: 1. optimizations 2.realizing associations between objects, classes 3.handling exceptions (“broken contracts”) 4.choosing a storage schema (e.g., in a database)

Useful mapping concepts for the object design model (examples): Access paths: does a sequence diagram show many similar traversals? Then you might want to create a direct path between the two objects If one class is accessing many objects of the same type, you might want to make the collection an indexed one to save time do some attributes in the called class really belong in the calling class?

Collapsing objects: Should some objects really be attributes? Delaying expensive computations Example: drawing an image—don’t create the image object until it is needed Caching the result of expensive computations Example: statistics calculations which will be referred to later in the program

Using efficient associations : Is the association: Unidirectional 1-1? Example: account is private so that account users cannot accidentally modify account number Bidirectional 1-1? Example: if an account has a reference to user, the user must have a reference to that account—if changes are made, both classes must be recompiled Bidirectional 1-many? A user can have several accounts; the accounts must be included in a “collection” of some kind—they might need to be ordered or unordered Many-many? Students-enrolled in classes: 2 lists—both must be consistent

Associations (continued): “qualified” association: example—”league” and “player” may be many-to-many, but a player can have a unique nickname in a given league May be able to use an “association class”— e.g., statistics —this class holds binary associations between objects

Mapping contracts to exceptions Java: throw / catch Simple method: check preconditions check postconditions check invariants encapsulate checking code into methods to deal with inheritance

Why is above “checking” procedure unrealistic? added code may be very long and complex, effort creating it may be better spent elsewhere more code means more chances for bugs code for checking is difficult to modify when original code is modified, this may lead to more bugs (“obfuscated code”) added code reduces performance efficiency

Note: adding error checking ALWAYS increases code length AND provides more opportunities for errors to occur (and is NOT foolproof) The same is true of error checking in general Example: simple error detection / correction in an n-bit string (Hamming) Detect 1 error: add parity bit, use xor Correct 1 error: if we add r bits, there are n + r + 1 possible cases for 1 error (n + r positions + “no error”) so we need room to store n + r + 1 results, i.e., 2 r > n + r + 1 Examples: if n = 8, need r = 4 check bits if n = 32, need r = 6

Heuristics for code-checking—do you agree with these? Omit checking postconditions and invariants—these are typically written by the code developer, tests should be written by an independent party Focus on subsystem interfaces—these are likely to be boundaries between developers; put less emphasis on checking private and protected methods Focus on components with the longest life, i.e., entity objects as opposed to interface objects Reuse constraint checking code where possible DOCUMENT the checking with comments

[Persistent storage mapping—we will not cover this, it is more relevant to databases]

Managing implementation: Core architect: selects transformations to be applied, e.g., storage method Architecture liaison: documents contracts for subsystem interfaces, keeps everyone up to date about these Developer: follows core architect’s conventions, converts object design model to source code, keeps source code documentation up to date

Ensuring consistency: --use tools consistently, don’t change development tools when you are working on a given transformation --keep the contracts in the source code, not in the object design model—this will increase the probability that they will be updated as needed --use the same names for the same objects --make transformations explicit

Question: is your coding style consistent with the recommendations given here?