Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures
|
|
- Elijah Dennis
- 6 years ago
- Views:
Transcription
1 Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov. 11, 2008
2 Lecture Overview Today Chapter 10 How to Generate Software Architectures Functional decomposition Impact of quality attributes on architectural design 2
3 Announcements Look at Appendix B. This is the full AquaLush Case Study including SRS, Use Cases, SAD, Refer to this before handing in deliverable 3
4 Architectural Design In architectural design, we specify: Structure -- the software program s major parts Responsibilities Properties Interfaces Behavior -- interactions among software program s major parts High-level description of structure and behavior is called a software architecture (This is where we are ) 4
5 Generating and Improving Architectures Generate candidate architectures How? First step in architectural design resolution Commonly used techniques Functional decomposition Quality attribute-based decomposition Modifying existing architecture Elaborate architectural style Transform conceptual model 5
6 Techniques to Generate Architectures 1) Functional decomposition Look at the functional requirements from the SRS and USE Case documentation that we have already generated. More Later. 2) Quality attribute-based decomposition Start with the non-functional requirements to begin creating the architecture. More later. 6
7 Techniques to Generate Architectures 3) Modifying existing architecture Do you have access to existing system. Perhaps it can be used as the basis for creating the architecture of the new system. This is not commonly used for a couple of reasons. 1) may have no access to a similar system. 2) if you do have access to an existing system, you are probably replacing it. If that is the case, one could study it to determine what deficiencies the current system contains. 7
8 Techniques to Generate Architectures 4) Elaborate architectural style Design Patterns. A general reusable solution to a commonly occurring problem in software design. In other words, a template to solve a problem that is adapted to your specific problem 5) Transform conceptual model Chapter 11 next week 8
9 Functional Decomposition Define functional components that are coherent collections of functional and data requirements Study SRS and USE Cases Brainstorm Candidate modules Relationships between modules 9
10 AquaLush Use Case Set Irrigation Parameters Start up Toggle Irrigation Operator Manual Control Irrigation Irrigate Valve Make Repairs Maintainer Report Failures Sensor 10
11 AquaLush Use Case Set Irrigation Parameters Start up User interface Irrigation Control Toggle Irrigation Operator Manual Control Irrigation Irrigate Valve Make Repairs Maintainer Report Failures Monitor and repair Sensor 11
12 AquaLush Functional Decomposition AquaLush prioritized requirements Configure program at startup Control irrigation Manually Automatically Provide user interface Allow users to monitor and repair system 12
13 Functional Decomposition Example: AquaLush Components Irrigation Control Startup Monitor and Repair User Interaction We are displaying all our major components with simple boxes along with a legend. Legend Functional Component What are we missing? 13
14 Functional Decomposition Example: AquaLush Component Interactions Who communicates with each other? Now we are getting there. We are using a simple box and line diagram. Still not completely finished. 14
15 Functional Decomposition Example: AquaLush Data Storage (Option 1) Monitor and Repair Legend AquaLush State Functional Component Data Store User Interaction x x Irrigation Control Startup AquaLush Configuration y y Interacts With x Reads & Writes y x Reads y The configuration data must be stored in permanent storage. Failed/repaired parts are also stored. How does Irrigation Control know when the system changes? Answer: Polling 15
16 Functional Decomposition Example: AquaLush Data Storage (Option 2) User Interaction Monitor and Repair Irrigation Control Startup In this design Monitor and Repair notifies Irrigation Control when a change is made. AquaLush State AquaLush Configuration Irrigation Control reads data store for current state. Legend Functional Component Data Store x x y y Interacts With x Reads & Writes y x Reads y There are tradeoffs here!!! Increased Coupling!!! 16
17 Quality Attribute-based Decomposition Define modules and relationships to satisfy quality attributes Add modules and relationships later to meet functional and data needs 17
18 Quality Attributes We ve heard of quality attributes before but we called them Non-functional requirements Classes of Quality Attributes Development attributes Operational attributes Define modules and relationships to satisfy nonfunctional requirements Add modules and relationships later to meet functional and data needs 18
19 Quality Attributes A quality attribute is is a characteristic or or property of of a software product independent of of its its function that is is important in in satisfying stakeholder needs. Also known as Non-functional requirement 19
20 Development Attributes Applies to the Developer: Maintainability Correctability fixing bugs as they appear Improvability adding functionality Portability moving to another platform Modifiability changing functionality Reusability Are we creating modules that may be used by other systems Is it a priority? 20
21 Development Attributes Testability Is the design done in a way that facilitates the testing process What attribute helps in creating a system that is easy to test? Answer: Low coupling 21
22 Development Quality Attributes Maintainability Degree to which a product can be corrected, improved, or ported Specific maintainability attributes Modifiability Portability Reusability Degree to which a product s parts can be reused in another product or future versions Testability Degree to which a product s associated requirements can be validated through testing 22
23 Operational Attributes Applies to the User, Customer and Developer: Performance Metric Latency startup time OR time delay between the moment something is initiated, and the moment one of its effects begins or becomes detectable Memory usage Throughput - the amount of work that a computer does in a given time period. ISDN has a latency of about 10ms. Its thoughput may only be twice that of a modem, but its latency is ten times better, and that's the key reason why browsing the web over an ISDN link feels so much better than over a modem. 23
24 Operational Quality Attributes Availability Reliability Security Readiness for use Metric: downtime Behaves according to requirements under normal operating conditions Metric: mean time to failure Resistance to harm or cause harm by hostile acts or influences 24
25 Architectural Decisions to Address Quality Attributes Performance Localize time-intensive operations and optimize minimize communications Use large rather than fine-grain components Security Use a layered architecture with critical assets in the inner layers Safety Localize safety-critical features in a small number of sub-systems Availability Include redundant components and mechanisms for fault tolerance Maintainability Use fine-grain, replaceable components 25
26 Architectural Conflicts Large-grain components improves performance reduces maintainability Redundant data improves availability makes security more difficult May decrease performance Localizing safety-related features simplifies security more communication so degraded performance 26
27 AquaLush Quality Attribute-based Decomposition AquaLush prioritized non-functional requirements 1. Reusability Main irrigation software components must be reused in future versions 2. Modifiability Must accommodate changes in irrigation strategy 3. Hardware adaptability Must work with various valve types, sensors, displays, keypads, screen buttons 4. Reliability We can trust the system to perform accurately 27
28 Quality Attribute Decomposition Example: Addressing Reusability Reusability requirements can be met by making parts highly modular Small, cohesive parts Parts hide information Loosely coupled to other parts Irrigation module must be reusable Create a separate irrigation module 28
29 Quality Attribute Decomposition Example: Addressing Modifiability Irrigation Control module must have modifiable strategies Can also be met by making Irrigation Control module highly modular Can replace or modify individual strategies Irrigation Control Manual Irrigation Control Automatic Irrigation Control Legend Module Part Of 29
30 Quality Attribute Decomposition Example: Addressing Hardware Adaptability A standard way to achieve hardware adaptability use a device interface module that contains virtual devices A virtual device is is a software simulation of, of, or or interface to, to, a real hardware device or or system. 30
31 Virtual Device Characteristics Simulates an ideal device that Does exactly one job completely (cohesion) Has a simple, consistent, complete interface (simplicity) Is loosely coupled to the rest of the program (coupling) Hides its implementation (information hiding) Never changes (stability) If physical device changes, only implementation of virtual device changes Not the virtual device interface! Typically realized as a family of components for different real devices or systems A device interface module, in our case 31
32 Virtual Device What is this is an example of? Design Pattern!!! The adapter design pattern 32
33 Quality Attribute Decomposition Example: Addressing Hardware Adaptability 33
34 Quality Attribute Decomposition Example: Addressing Reliability One strategy for making systems reliable is to make modules small and interactions simple Already the case here! 34
35 Quality Attribute Decomposition Example: Addressing Missing Requirements User Interface Irrigation Control Manual Irrigation Control Automatic Irrigation Control Need a user interface! Valve Sensor Device Interface Display Keypad Screen Buttons Legend Module Interacts With Part Of 35
36 The 2 Architectures: User Interface Irrigation Control Manual Irrigation Control Automatic Irrigation Control Valve Sensor Device Interface Display Keypad Screen Buttons Legend Module Interacts With Part Of 36
37 Generating Architectures Commonly used techniques Functional decomposition Quality attribute-based decomposition Transform conceptual model (next week) Modifying existing architecture (we don t have one) Elaborate architectural style (soon) 37
38 Architectural Design Process We ve generated Now, how do we: Improve? Evaluate? Select? SRS Architectural Design Process SRS : Problem SAD : Solution Analyze SRS Generate/Improve Candidate Architectures Evaluate Candidate Architectures Select Architecture [else] [adequate architecture] Finalize Architecture SAD 38
39 Improving Architectural Alternatives Combine Alternatives Combine the best features of two or more alternatives Example: Combine quality attribute generated with function decomposition generated alternatives Impose an Architectural Style Modify an architecture that almost fits a style so that it does fit the style Apply Mid-Level Design Patterns Modify an architecture to take advantage of mid-level design patterns 39
40 Evaluating Architectural Alternatives Two primary techniques Scenarios Prototypes Techniques may be complementary 40
41 Evaluating and Selecting with Scenarios Walk through each scenario Judge how well a design alternative supports the scenario Record a judgment for each scenario Use a selection technique to choose an alternative Pros and cons (compare strengths and weaknesses) Multi-dimensional ranking Scoring matrix 41
42 Creating Profiles and Scenarios A utility tree is a tree whose sub-trees are profiles and whose leaves are scenarios Label the root utility Add children with profile names that reflect product requirements Fill in scenarios for each profile Brainstorm scenarios Rationalize the list Weight each scenario Eliminate low-weight scenarios until each profile has 3 to 10 leaves Write scenario descriptions 42
43 Example Utility Tree AquaLush Utility Tree Profiles correspond to nonfunctional and functional requirements! Importance of Scenario (weight) Functional requirements Non-functional requirements 43
44 Scoring Matrix Quantify the scenario values (H = 3, M = 2, L = 1) Normalize so that the sum of the scenario weights are 1. Do this by dividing the scenario values by the sum of the scenario weights. Create the scoring matrix for all candidate architectures See Fig (p. 306) 44
45 Scenario Add a Valve type A developer modifies the AquaLush source code and design documents so that AquaLush supports a new type of valve. The developer completes the process in two days. How do the two designs handle this scenario? 45
46 Evaluating and Selecting with Prototypes Prototypes may be built to test out design alternatives Scenario walkthroughs may give rise to a need for prototyping Prototypes provide the factual basis for selection using Pros and cons (examine strength and weaknesses) Multi-dimensional ranking (scoring matrix) Disadvantage - expensive 46
47 Summary Generating Software Architectural Designs Using: 1) Functional Requirements 2) Quality Attributes 47
Introduction to Software Engineering. ECSE-321 Unit 9 Architectural Design Approaches
Introduction to Software Engineering ECSE-321 Unit 9 Architectural Design Approaches Requirement Elicitation Analysis (Software Product Design) Architectural Design Detailed Design Architectural Design
More informationLecture 16: (Architecture IV)
Lecture 16: (Architecture IV) Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct.
More informationCHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN
CHAPTER 5 ARCHITECTURAL DESIGN SE211 SOFTWARE DESIGN Assist. Prof. Dr. Volkan TUNALI Faculty of Engineering and Natural Sciences / Maltepe University OVERVIEW 2 SECTION 1 Architectural Design SECTION 2
More informationLecture 9 Requirements Engineering II
Lecture 9 Requirements Engineering II Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 23, 2008 Announcements
More informationLecture 8 Requirements Engineering
Lecture 8 Requirements Engineering Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte September 18, 2008 Lecture Overview
More informationLecture 13 Introduction to Software Architecture
Lecture 13 Introduction to Software Architecture Software Systems Design and Implementation ITCS/ITIS 6112/8112 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationObjectives. Architectural Design. Software architecture. Topics covered. Architectural design. Advantages of explicit architecture
Objectives Architectural Design To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationLecture 17 Engineering Design Resolution: Generating and Evaluating Architectures
Lecture 17 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at
More informationArchitectural Design
Architectural Design Objectives To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
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 ARCHITECTURE & DESIGN INTRODUCTION
SOFTWARE ARCHITECTURE & DESIGN INTRODUCTION http://www.tutorialspoint.com/software_architecture_design/introduction.htm Copyright tutorialspoint.com The architecture of a system describes its major components,
More informationEngr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila Software Design and Architecture Software Design Software design is a process of problem-solving
More informationLecture 13: Analysis Modeling
Lecture 13: Analysis Modeling Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct. 16, 2008 Announcements Midterms graded
More informationUnit 1 Introduction to Software Engineering
Unit 1 Introduction to Software Engineering João M. Fernandes Universidade do Minho Portugal Contents 1. Software Engineering 2. Software Requirements 3. Software Design 2/50 Software Engineering Engineering
More information5/9/2014. Recall the design process. Lecture 1. Establishing the overall structureof a software system. Topics covered
Topics covered Chapter 6 Architectural Design Architectural design decisions Architectural views Architectural patterns Application architectures Lecture 1 1 2 Software architecture The design process
More informationLecture 2 Software Engineering and Design
Lecture 2 Software Engineering and Design Software Engineering ITCS 3155 Spring 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte August 28, 2008 Lecture Overview
More informationSoftware Engineering
Software Engineering Engr. Abdul-Rahman Mahmood MS, MCP, QMR(ISO9001:2000) Usman Institute of Technology University Road, Karachi armahmood786@yahoo.com alphasecure@gmail.com alphapeeler.sf.net/pubkeys/pkey.htm
More informationArchitectural Design. Topics covered. Architectural Design. Software architecture. Recall the design process
Architectural Design Objectives To introduce architectural design and to discuss its importance To explain the architectural design decisions that have to be made To introduce three complementary architectural
More informationLecture 6: Requirements Engineering
Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationChapter 6 Architectural Design. Chapter 6 Architectural design
Chapter 6 Architectural Design 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process for identifying
More informationChecklist for Requirements Specification Reviews
Checklist for Requirements Specification Reviews Organization and Completeness o Are all internal cross-references to other requirements correct? o Are all requirements written at a consistent and appropriate
More informationAttribute-Driven Design
Attribute-Driven Design Minsoo Ryu Hanyang University msryu@hanyang.ac.kr Attribute-Driven Design The ADD method is an approach to defining a software architecture in which the design process is based
More informationPresenter: Dong hyun Park
Presenter: 200412325 Dong hyun Park Design as a life cycle activity bonds the requirements to construction Process of breaking down the system into components, defining interfaces and defining components
More informationIntroduction to Architecture. Introduction to Architecture 1
Introduction to Architecture Introduction to Architecture 1 Content What is architecture? Motivation for architecture Non-functional requirements Introduction to Architecture 2 What is architecture? The
More informationLecture 21: Design Patterns III
Lecture 21: Design Patterns III Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov.
More informationLecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered Architectural design decisions Architectural views Architectural patterns Application architectures 2 Software architecture The design process
More informationLectures 24 and 25 Introduction to Architectural Styles and Design Patterns
Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationLecture 19: Introduction to Design Patterns
Lecture 19: Introduction to Design Patterns Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More information<Name of the project> Software Requirement Specification
Software Requirement Specification Project Code: Document Code: v RECORD OF CHANGE *A -
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 informationIn this Lecture you will Learn: Design Patterns. Patterns vs. Frameworks. Patterns vs. Frameworks
In this Lecture you will Learn: Design Patterns Chapter 15 What types of patterns have been identified in software development How to apply design patterns during software development The benefits and
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures PART 1 ARCHITECTURAL DESIGN DECISIONS Recap on SDLC Phases
More informationThe Software Design Process. CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed
The Software Design Process CSCE 315 Programming Studio, Fall 2017 Tanzir Ahmed Outline Challenges in Design Design Concepts Heuristics Practices Challenges in Design A problem that can only be defined
More informationTerminology. There are many different types of errors and different ways how we can deal with them.
Testing Terminology Reliability: The measure of success with which the observed behavior of a system confirms to some specification of its behavior. Failure: Any deviation of the observed behavior from
More informationArchitectural Design
Architectural Design Topics i. Architectural design decisions ii. Architectural views iii. Architectural patterns iv. Application architectures Chapter 6 Architectural design 2 PART 1 ARCHITECTURAL DESIGN
More informationObject-Oriented Software Engineering Conquering Complex and Changing Systems. Chapter 9, Testing
Object-Oriented Software Engineering Conquering Complex and Changing Systems Chapter 9, Testing Preliminaries Written exam on for Bachelors of Informatik, and for other students who are not in the Informatik
More informationSession 4b: Review of Program Quality
Session 4b: Review of Program Quality What makes one program "better" than another? COMP 170 -- Fall, 2013 Mr. Weisert What is a good program? Suppose we give the same assignment to two programmers (or
More informationCS 292 Software Development
CS 292 Software Development and Professional Practice Structured Design and More Design Principles CS 292 Design Principles 1 Unless otherwise expressly stated, all original material of whatever nature
More informationCHAPTER 3 ASYNCHRONOUS PIPELINE CONTROLLER
84 CHAPTER 3 ASYNCHRONOUS PIPELINE CONTROLLER 3.1 INTRODUCTION The introduction of several new asynchronous designs which provides high throughput and low latency is the significance of this chapter. The
More informationLecture 26: Testing. Software Engineering ITCS 3155 Fall Dr. Jamie Payton
Lecture 26: Testing Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Dec. 9, 2008 Verification vs validation Verification:
More informationLecture 9: MIMD Architectures
Lecture 9: MIMD Architectures Introduction and classification Symmetric multiprocessors NUMA architecture Clusters Zebo Peng, IDA, LiTH 1 Introduction A set of general purpose processors is connected together.
More informationIntroduction to Software Engineering
Introduction to Software Engineering Gérald Monard Ecole GDR CORREL - April 16, 2013 www.monard.info Bibliography Software Engineering, 9th ed. (I. Sommerville, 2010, Pearson) Conduite de projets informatiques,
More informationProducts of Requirements elicitation and analysis. Chapter 6: System design: decomposing the system
Products of Requirements elicitation and analysis Chapter 6: System design: decomposing the system Requirements! elicitation! Requirements! Specification! nonfunctional! requirements! functional! model!
More informationUNIT OBJECTIVE. Understand what system testing entails Learn techniques for measuring system quality
SYSTEM TEST UNIT OBJECTIVE Understand what system testing entails Learn techniques for measuring system quality SYSTEM TEST 1. Focus is on integrating components and sub-systems to create the system 2.
More informationTesting. Outline. What is this? Terminology. Erroneous State ( Error ) Algorithmic Fault
Outline 1 Terminology Types of errors Dealing with errors Quality assurance vs Component Unit testing Integration testing Strategy Design Patterns & testing unction testing Structure Performance testing
More informationRequirement Analysis
Requirement Analysis Requirements Analysis & Specification Objective: determine what the system must do to solve the problem (without describing how) Done by Analyst (also called Requirements Analyst)
More informationBDSA08 Advanced Architecture
UI Swing not the Java Swing libraries, but our GUI classes based on Swing Web Domain Sales Payments Taxes Technical Services Persistence Logging RulesEngine BDSA08 Advanced Architecture Jakob E. Bardram
More informationTechnical Metrics for OO Systems
Technical Metrics for OO Systems 1 Last time: Metrics Non-technical: about process Technical: about product Size, complexity (cyclomatic, function points) How to use metrics Prioritize work Measure programmer
More informationChapter 6 Architectural Design. Lecture 1. Chapter 6 Architectural design
Chapter 6 Architectural Design Lecture 1 1 Topics covered ² Architectural design decisions ² Architectural views ² Architectural patterns ² Application architectures 2 Software architecture ² The design
More informationSE 2730 Final Review
SE 2730 Final Review 1. Introduction 1) What is software: programs, associated documentations and data 2) Three types of software products: generic, custom, semi-custom Why is semi-custom product more
More informationNatural Language Specification
REQUIREMENTS ENGINEERING LECTURE 2017/2018 Dr. Jörg Dörr Natural Language Specification Most Requirements are Described in Natural Language Free Text (Prose) In Word In Excel (Tabular) In RM-Tools In Sys-ML
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationProposed Unified ility Definition Framework. Andrew Long October 2012
Identify, Innovate Explore, Engineer - Execute 1 1 Proposed Unified ility Definition Framework Andrew Long October 2012 Identify, Innovate Explore, Engineer - Execute 2 2 Motivation Increased interest
More informationChapter Outline. Chapter 2 Distributed Information Systems Architecture. Distributed transactions (quick refresh) Layers of an information system
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 2 Distributed Information Systems Architecture Chapter Outline
More informationObject Oriented Programming
Binnur Kurt kurt@ce.itu.edu.tr Istanbul Technical University Computer Engineering Department 1 Version 0.1.2 About the Lecturer BSc İTÜ, Computer Engineering Department, 1995 MSc İTÜ, Computer Engineering
More informationLecture 17: (Architecture V)
Lecture 17: (Architecture V) Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct. 30,
More informationSYSTEM UPGRADE, INC Making Good Computers Better. System Upgrade Teaches RAID
System Upgrade Teaches RAID In the growing computer industry we often find it difficult to keep track of the everyday changes in technology. At System Upgrade, Inc it is our goal and mission to provide
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 informationAbout Dean Leffingwell
Lean Practices for Foreword by Don Nonfunctional (System Qualities) Agile Style Reinertsen Development Series By and Ryan Shriver Agile 2010 Orlando, FL Lean Practices for Foreword by Don Reinertsen Development
More informationCS504-Softwere Engineering -1 Solved Subjective Midterm Papers For Preparation of Midterm Exam
CS504-Softwere Engineering -1 Solved Subjective Midterm Papers For Preparation of Midterm Exam CS504 Subjective Midterm Examination 2011 Question No: 1 ( Marks: 3 ) Define Asynchronous Messages and Synchronous
More informationSetting the stage... Key Design Issues. Main purpose - Manage software system complexity by improving software quality factors
Setting the stage... Dr. Radu Marinescu 1 1946 Key Design Issues Main purpose - Manage software system complexity by...... improving software quality factors... facilitating systematic reuse Dr. Radu Marinescu
More informationVETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
VETRI VINAYAHA COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS6403 SOFTWARE ENGINEERING II year/ IV sem CSE (Regulation 2013) UNIT 1- SOFTWARE PROCESS AND PROJECT
More informationTrusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout
1 Last update: 2 November 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout 2 Lecture 12: Componentization Agenda for today 3 Componentization Componentizability
More informationMining Social Network Graphs
Mining Social Network Graphs Analysis of Large Graphs: Community Detection Rafael Ferreira da Silva rafsilva@isi.edu http://rafaelsilva.com Note to other teachers and users of these slides: We would be
More informationCh 1: The Architecture Business Cycle
Ch 1: The Architecture Business Cycle For decades, software designers have been taught to build systems based exclusively on the technical requirements. Software architecture encompasses the structures
More informationICS 52: Introduction to Software Engineering
ICS 52: Introduction to Software Engineering Fall Quarter 2002 Professor Richard N. Taylor Lecture Notes Week 2: Principles and Requirements Engineering http://www.ics.uci.edu/~taylor/ics_52_fq02/syllabus.html
More information<Project Name> Vision
Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=infoblue) is included
More informationSystems-Level Architecture. A Re-Introduction Arch. Reintro CSC Level of Design. Divide into two levels:
Systems-Level Architecture A Re-Introduction 12 - Arch. Reintro CSC407 1 Level of Design Divide into two levels: System-LevelArchitecture Programming-Level Design You know what design is OOD + written
More informationAdapted from: The Human Factor: Designing Computer Systems for People, Rubinstein & Hersh (1984) Designers make myths. Users make conceptual models.
User Interface Guidelines UI Guidelines 1 Adapted from: The Human Factor: Designing Computer Systems for People, Rubinstein & Hersh (1984) Know your users - they are not you Designers make myths. Users
More informationA survey of methods and approaches for reliable dynamic service compositions
SOCA (2014) 8:129 158 DOI 10.1007/s11761-013-0153-3 ORIGINAL RESEARCH PAPER A survey of methods and approaches for reliable dynamic service compositions Anne Immonen Daniel Pakkala Received: 13 June 2013
More informationSystem Design and Modular Programming
CS3 Programming Methodology Lecture Note D1, 2 November 2000 System Design and Modular Programming System design involves meeting competing requirements and satisfying constraints on the system and the
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 informationSoftware Requirements Specification. <Project> for. Version 1.0 approved. Prepared by <author(s)> <Organization> <Date created>
Software Requirements Specification for Version 1.0 approved Prepared by Software Requirements Specification for Page 2 Table of Contents Revision
More informationSOFTWARE ARCHITECTURES UNIT I INTRODUCTION AND ARCHITECTURAL DRIVERS
IT6602 SOFTWARE ARCHITECTURES UNIT I INTRODUCTION AND ARCHITECTURAL DRIVERS SYLLABUS: Introduction What is software architecture? Standard Definitions Architectural structures Influence of software architecture
More informationCHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS
CHAPTER 4 HEURISTICS BASED ON OBJECT ORIENTED METRICS Design evaluation is most critical activity during software development process. Design heuristics are proposed as a more accessible and informal means
More informationModeling Issues Modeling Enterprises. Modeling
Modeling Issues Modeling Enterprises SE502: Software Requirements Engineering Modeling Modeling can guide elicitation: It can help you figure out what questions to ask It can help to surface hidden requirements
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 informationSoftware Architecture
Software Architecture Architectural Design and Patterns. Standard Architectures. Dr. Philipp Leitner @xleitix University of Zurich, Switzerland software evolution & architecture lab Architecting, the planning
More informationCorso di Progettazione di Applicazioni Web e Mobile
Corso di Progettazione di Applicazioni Web e Mobile Mirko Calvaresi Università di Camerino - Mirko Calvaresi - Progettazione Applicazioni Web e Mobile What this is about? How a web appliaction works? let
More informationLecture 20: Design Patterns II
Lecture 20: Design Patterns II Software System Design and Implementation ITCS/ITIS 6112/8112 001 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov.
More informationKeywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.
Comparative Study In Utilization Of Creational And Structural Design Patterns In Solving Design Problems K.Wseem Abrar M.Tech., Student, Dept. of CSE, Amina Institute of Technology, Shamirpet, Hyderabad
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 informationSoftware Design Fundamentals. CSCE Lecture 11-09/27/2016
Software Design Fundamentals CSCE 740 - Lecture 11-09/27/2016 Today s Goals Define design Introduce the design process Overview of design criteria What results in a good design? Gregory Gay CSCE 740 -
More informationChapter Outline. Chapter 2 Distributed Information Systems Architecture. Layers of an information system. Design strategies.
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 2 Distributed Information Systems Architecture Chapter Outline
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 informationME 4054W: SENIOR DESIGN PROJECTS
ME 4054W: SENIOR DESIGN PROJECTS Week 3 Thursday Documenting Your Design Before we get started We have received feedback from an industry advisor that some of the students on their design team were not
More informationInformation System Architecture. Indra Tobing
Indra Tobing What is IS Information architecture is the term used to describe the structure of a system, i.e the way information is grouped, the navigation methods and terminology used within the system.
More informationTHOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS
THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS LOGISTICS HW3 due today HW4 due in two weeks 2 IN CLASS EXERCISE What's a software design problem you've solved from an idea you learned from someone else?
More informationSoftware Engineering (CSC 4350/6350) Rao Casturi
Software Engineering (CSC 4350/6350) Rao Casturi Testing Software Engineering -CSC4350/6350 - Rao Casturi 2 Testing What is testing? Process of finding the divergence between the expected behavior of the
More informationRequirements Analysis
Requirements Analysis Software Requirements A software (product) requirement is is a feature, function, capability, or property that a software product must have. Software Design A software design is is
More informationCreating and Analyzing Software Architecture
Creating and Analyzing Software Architecture Dr. Igor Ivkovic iivkovic@uwaterloo.ca [with material from Software Architecture: Foundations, Theory, and Practice, by Taylor, Medvidovic, and Dashofy, published
More informationCharacteristics of Mult l ip i ro r ce c ssors r
Characteristics of Multiprocessors A multiprocessor system is an interconnection of two or more CPUs with memory and input output equipment. The term processor in multiprocessor can mean either a central
More informationChapter 11, Testing. Using UML, Patterns, and Java. Object-Oriented Software Engineering
Chapter 11, Testing Using UML, Patterns, and Java Object-Oriented Software Engineering Outline Terminology Types of errors Dealing with errors Quality assurance vs Testing Component Testing! Unit testing!
More informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 11/10/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 11/10/2015 http://cs.gsu.edu/~ncasturi1 Class announcements Final Exam date - Dec 1 st. Final Presentations Dec 3 rd. And
More informationModel-based Transition from Requirements to High-level Software Design
Model-based Transition from Requirements to High-level Software Institut für Computertechnik ICT Institute of Computer Technology Hermann Kaindl Vienna University of Technology, ICT Austria System overview
More informationLecture (08, 09) Routing in Switched Networks
Agenda Lecture (08, 09) Routing in Switched Networks Dr. Ahmed ElShafee Routing protocols Fixed Flooding Random Adaptive ARPANET Routing Strategies ١ Dr. Ahmed ElShafee, ACU Fall 2011, Networks I ٢ Dr.
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 informationRequirements Engineering: Specification & Validation. Software Requirements and Design CITS 4401 Lecture 18
Requirements Engineering: Specification & Validation Software Requirements and Design CITS 4401 Lecture 18 The Problems of Requirements What goal(s) are we trying to satisfy? How do we identify the scope
More informationSoftware Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 11/10/2014 Final Exam date - Dec 10 th? Class announcements Final Presentations Dec 3 rd. And Dec 8 th. Ability
More informationFinding a Needle in a Haystack. Facebook s Photo Storage Jack Hartner
Finding a Needle in a Haystack Facebook s Photo Storage Jack Hartner Paper Outline Introduction Background & Previous Design Design & Implementation Evaluation Related Work Conclusion Facebook Photo Storage
More information