System Design and Modular Programming
|
|
- Annice Blair
- 5 years ago
- Views:
Transcription
1 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 system development process. The system should satisfy the functional requirements and the measurable attributes of the system should be adequate (e.g. efficiency, reliability, maintainability, usability). The development process is constrained by cost, available staff, external regulation, etc. The final system represents a compromise that attempts to satisfy these competing requirements and constraints. The approach to satisfying the requirements depends on the chosen lifecycle. Waterfall takes the specification as a target and attempts to meet it. The spiral model sees successive prototypes as approximations to the ideal specification (the specification may change as a result of prototyping). Evolutionary delivery attempts to partition the specification into many small sub-specifications and attempts to meet each sub-specification with a product delivered to the customer (the specification may change as a result of earlier delivery). This note is an overview of the design process. We consider what a design should contain, the design process, criteria to judge the quality of a design, an overview of design techniques, the design evaluation process and how structured approaches to design can be supported by programming language structures. These components will play a part in the design process in whatever lifecycle model structures the development process. The distribution of the activities will be different but all will take place. System Design In design the problem specified by the requirements specification is solved, either completely (waterfall), or approximately (spiral) or partially (evolutionary). For most real-world systems this solution takes two forms: the conceptual design and the technical design. The technical design is an internal document and forms the specification from which detailed program design is undertaken. The conceptual design is derived from the technical design and is intended for presentation to the individual or group who commissioned the project. Technical Design The technical design should specify: 1. the hardware required, 2. the structure of the software to a level of detail that provides the facilities in the requirements specification, and 3. the specification of the data structures and data flows. Traditionally, the hardware has been specified by providing an architecture that specifies the hardware components and the data flow connections between the components. More recently software architecture has become an area of intense study and the large-scale structure of the software is described by identifying the components of the system and how they interconnect via different style of connector. We return to software architecture in later notes. In Computer Science it is common to make no distinction between items 2 and 3 above. The reason for separating them out in the literature on system design is pragmatic. Many commercial systems have large volumes of stored data and it is important to identify different collections of data and to document the existing format of the data and the format of any new data generated by the system. Many commercial systems follow uncomplicated procedures requiring little in the way of programming but they do require tight control over very large 1
2 volumes of data which may be of a sensitive nature. In these systems much of the time of the designer is occupied in ensuring that security and recovery procedures are adequate. An important aspect of the design is that it provides a trace back to the specification. The justification for the inclusion of any particular feature of the design must be justified in terms of some aspect of the specification (or in support of some design feature that implements some aspect of the specification, and so on...). Since the specification should be traceable back to requirements, all aspects of the design should ultimately be justified from the requirements. Conceptual Design The conceptual design must be comprehensible by non-designers. The conceptual design is often the document on which contracts are agreed so it is important that it is accurate. Though this is not an exhaustive list the conceptual design should have the following features: (i) it should be derived from the technical design, (ii) it should be comprehensible by the commissioner of the project, (iii) it contains no technical jargon, (iv) it describes the humancomputer interaction of the system (v) it describes the functions provided by the system (vi) it is independent of implementation issues (vii) it makes clear how all components relate to the requirements, which requirements are met and which are not. This information must be presented in sufficient detail that the commissioner of the project can make informed comment on the design and is able to tell whether it meets the requirements adequately. The conceptual design should be traceable back to the specification. Design Process The primary goal of the design process is to ensure that the requirements are met. There are three dominant approaches to design: Decomposition (top-down): This takes the functional component of the requirements as primary and attempts to solve the problem by decomposing it into subproblems and methods for combining solutions to the subproblems to solve the main problem. The non-functional requirements are taken as constraints on the solution proposed at each decomposition step. The structure of the decomposition provides the modules comprising the final system design. Composition (bottom-up): This takes the collections of data in the system as primary and attempts to compose collections of data and the operations defined on them to composite collections of data with more complex operations defined on the composite. Again this results in a modular decomposition but it is constructed bottom-up. This approach is favoured by those who advocate object-oriented design. (Object oriented techniques are dealt with in the companion course, Software Engineering with Objects and Components.) Architectural: Recently, software architecture [7] has become a popular method of bridging the gap between high-level specifications and low level libraries. An architecture is a collection of components, connected in a configuration by some connectors. The idea is to fix the gross structure of the system in some detail. This structure allows detailed design of the components within an agreed structure. Architectures can be complex, and represent a significant portion of the design effort, but they persist from system to system thereby promoting reuse. They are also strong determinants of the ease of demonstrating certain functional characteristics of the system and provide the basis for tradeoff analysis for the measurable attributes between one architecture and another. An architectural style is defined by the kinds of components and connectors we allow. For example, if the connectors allow data flow (e.g. UNIX pipes ) then we have a data flow style, other styles might be message passing or signal processing or polled units. Each will have strengths in different areas of application. 2
3 There is no standard approach to system design and the approaches to it remain somewhat informal. However, the structured method approach has become popular in commercial environments. These approaches should not be confused with mathematical methods. Structured methods define a particular strategy for tackling classes of commonly occurring problems. Generally these methods permit the designer to describe the system by viewing it from different angles and allow for testing the consistency of these views 1. Most commonly they provide: 1. An entity-relationship view of the system describing the data in the system and how it is related. This provides a high-level view of the system concentrating on data and their relationships. 2. A data flow view in which the system is modelled by the flow of data in the system and the transformations that take place as it is processed. 3. A structured view of the functionality where large-scale functions are expressed as compositions of smaller functional components. There is a wide range of such methods including structured design [2], structured systems analysis [4] and RAPID/USE [8]. A special issue of IEEE Transactions on Software Engineering [5] outlines some different approaches to system design. Design Quality Though the primary aim of the design process is to meet the specification, the quality of a design has a profound influence on modifiability, maintainability, reliability and testability of a system. The idea of the quality of a design has grown up around structured methods and are therefore oriented towards measuring the quality of the decomposition of the system into separate components or modules. Attributes of modules can be useful in assessing the quality of a design. Though this is not an exhaustive list it is helpful in guiding the design towards a decomposition that eases implementation, testing and maintenance: Cohesion: Modules should be as cohesive as possible. Generally module systems are designed to limit the visibility of objects and their representation. A group of objects (i.e. functions, types, data etc.) cohere if they require the visibility of similar objects at a similar level of abstraction. Do not dump functions and types together for no good reason. If the result is not cohesive, think about splitting the module. Of course there are different criteria for cohesion. For example: definitional cohesion (components are interdefined), temporal cohesion (components are active at the same phase in the computation), location cohesion (components are active at the same site in a distributed system), communication cohesion (components pass messages between themselves), and functional cohesion (components all contribute to a particular user function) Coupling: Aim for a system with a low level of dependency or coupling between modules. Modules that depend on many other modules are undesirable because modification in any one of these may require it to be changed. Modules that are required by many modules should also be avoided because change in such modules may require a large number of modules to change. The criteria for coupling are diverse: definitional coupling (the definition of one module uses another), shared reference (modules share assignable store or files), shared data types, shared structures. Comprehensibility: This is particularly important in the maintenance phase of the system lifecycle. Generally the maintainer will be different from the author of a module and thus the comprehensibility of a module is important if it is to be redesigned. The following are important in assessing comprehensibility: 1 You will see one structured method approach when you study UML in Software Engineering with Objects and Components. 3
4 Naming: Are the names meaningful? Do they reflect the meaning of the real-world action/entity they model? Documentation: is the module adequately documented? Complexity: are the algorithms used easily comprehensible? Modifiability: Most important here is relatively loose coupling so design changes propagate only locally. Cohesion is also important here because the more self-contained a module is the fewer changes will be required in a redesign. Finally, low complexity is important if the module is to be capable of safe redesign. The time and effort taken to generate a design may be considerable, but it is still substantially less than that required to implement a system. The system design phase is the time to evaluate a diverse collection of solutions to the problems presented by a system. Usually it is assumed that all systems being evaluated meet the basic requirements of the system but they may differ widely when attributes like cohesion, coupling, comprehensibility, modifiability, testability and efficiency are taken into account. Often these considerations are crucial in making the choice between potential system designs. Design Techniques The literature abounds with techniques and tools to document and control the design process. As well as those cited earlier in the discussion on structured methods we have, for example, [3, 6]. SSADM is a particular approach to the design of systems [1]. This is mandated by the UK government for certain classes of data-processing applications. SSADM is typical of these techniques in having a strong bias towards one particular class of system. Generally speaking, techniques of system design involve modelling the data and control in a system and then automating and augmenting the functions carried out by the agents in the system. The representation of the system components is usually diagrammatic. The following kinds of information are seen as being useful: Data Structure Diagrams: These give a broad brush view of the data stored by the system. They generally describe each collection of data in the system (and are backed up by forms describing the structure and format of each collection). In addition the relationships between the data collections are documented. These relationships are important to the consistency of the data. For example, in an inventory control system one may have product data that records, for every product, the reference number of all the components in the product and component data recording the supplier of every component. An important relation between product and component is that every component in the product database appears in the component data base. Data Flow Diagrams: These document the flow of data in the system. They document input and output databases for system functions and may specify intermediate databases to be created by the system. Often the system functions are simple and the data flow diagram can specify them. Structure Charts: If system functions are complex some form of structure chart may be used to decompose system functions into sub-functions and specify: choice, iteration etc. A typical example of this kind of diagram may be found in [6]. Figure 1 illustrates each of the different kinds of diagram. In the data structure diagram the arcs represent relationships between the different collections of data in the system. In the data flow diagram the flows of different kinds of data are represented together with the transactions carried out on them. In the structure chart the make transaction diagram is decomposed into sub-operations. At the top level there is choice between three different types of transactions (represented by the o for option in the second level boxes) and at the second level the keycard 4
5 transaction is further decomposed. The structure chart notation is further augmented with notations for iteration to indicate that a particular operation may be repeated some number of times. If some non-functional requirement is particularly important it may be necessary to employ prototypes to decide if that requirement can be met. Typical non-functional requirements are the usability of the human interface or performance requirements for the responsiveness of the system. Design Reviews Design reviews play an important rôle in deciding whether a system design meets all the requirements. Usually there are two meetings: the preliminary review in which some semicompleted designs are presented and the critical review in which the final design is reviewed. The structure of the preliminary design review meeting is: Membership: Commissioners of the project, potential users, requirements analyst, system designers, a moderator, a secretary, other designers and analysts not involved in the project. Input Documents: Requirements, initial system design(s). Schematic Agenda: The following points should be covered: Hardware required by the design. Functionality of the design. Performance of the design. Human interface. Interfaces to other systems Output Documents: Report of the review, requests for revisions of the requirements, areas requiring further design. The rôle of the secretary is purely to maintain a fair record of the meeting. The moderator should be ensuring that the main orientation is that the requirements are met and if necessary clarified and that quality of design is paramount. The rôles of the other members of the meeting should be obvious. The critical design review is similar to this but program designers are present and an expected outcome is an agreed system design. Documentation An important input to the design reviews and the final outcome of the design process is the conceptual design. The design process is primarily driven by the needs of the technical design but the documentation should be prepared to contribute to the conceptual design. The following should be described in non-technical diagrams and words: Hardware structure. The human interface: menus, formats, interaction methods, reports, error reporting and recovery. Inputs required from the system: source and format information. Outputs generated by the system: destination and format information. Functionality: modular structure of the system. Performance estimates. Security, recovery, error detection. 5
6 Customer Transaction customer transactions MAKE TRANSACTION statements debit/credit 6 Figure 1: Some kinds of diagram used in design Account DATA STRUCTURE DIAGRAM MAKE TRANSACTION o o TELLER KEYCARD DIRECT DEBIT o ACCOUNT DATA FLOW DIAGRAM accept card do request return card STRUCTURE CHART
7 Modular Programming The argument for the provision of modular programming facilities is that the modular level should take care of large scale issues while normal programming languages provide small scale facilities. Small scale programming involves the algorithmic solution of particular problems, issues of data structure choice and the efficiency of particular methods. By contrast large-scale programming involves the overall structure of the system, how its parts relate, the visibility of names and so on. Structure Hiding The ability to hide structure is crucial to the construction of large scale systems. Ensuring that certain details of the system are denied to other designers and users is a means to control the complexity of systems. The commonest use of structure hiding is in the provision of abstract data types where we deny access to the implementing structures to all functions other than those implementing the data type. The notion is more generally useful since we often want to hide subsidiary functions and often in systems with state it is useful to partition the store between different modules thereby ensuring that certain parts of the store can only be affected by a specified group of functions. This method of controlling store access is an attractive part of the object-oriented approach. Dependency Structure Providing the means to explicitly specify the functions, types etc. required by a module provides a means of tracking the potential effects of change in a particular module through the rest of the system. By running along the chain of dependencies one should be able to find all the potentially affected modules. In practice the efficacy of this approach can be undermined by failures in the type system coupled to the use of store in modules, but it remains a useful tool in controlling the effects of change. Examining the dependency structure of a system can also help the designer restructure systems displaying undesirable features. Typical problems are: One module A may depend on many other modules. This indicates either that A is too large and should be subdivided, or that intermediate modules are necessary between A and the modules it depends on to build intermediate structures from which A can be constructed. A module A may contribute directly to many other modules. Again this suggests that A may be too large and can be split into two simpler modules, or that the facilities provided by A are too primitive for the modules using it. In the latter case it may be necessary to construct new modules derived from A to provide higher-level facilities to be used by the modules that formerly used A directly. System Building In subdividing the work of building systems, often all we need to know about other modules is the interface they present to the outside world, i.e. the visible functions and types provided by the module. By separating the interface from the implementation, module systems allow the independent construction of modules by different designers. The provision of dependency information and the specification of module interfaces provides opportunities for tools that reduce the amount of effort required to compile and rebuild systems when they are modified. Because the dependency information and interface are explicitly provided, it is possible to separately compile modules and it is also possible to determine which modules require re-compilation or linking when a module is modified. 7
8 Software Reuse The interface that is associated with an implementation documents the facilities provided by that code. The existence of the interface encourages the disciplined re-use of existing code rather than an ad hoc approach involving either the development of new code or the piecemeal modification of existing code. Different interfaces can be associated with the same code when it is used for different purposes, taking advantage of the separation of interface from implementation. Modular Programming Facilities All the above considerations have shaped the formulation of a variety of approaches to the modularisation of code. These vary from the informal but disciplined use of files to provide modular structure commonly practised by C programmers to languages incorporating module facilities e.g. Modula-2 [9] or ML. There is a substantial level of agreement that a reasonable module system should incorporate at least the following facilities: Hiding: Some means should be given to hide structures: functions, procedures, types, stores etc. Dependency: The facility to express what objects are required by a particular module and what other modules should provide them. Interfaces: The existence of interfaces as independent entities expressing the facilities provided by a module but not the method by which they are provided. Implementations: The possibility to link code to interfaces and check that the implementation provides the facilities promised by the interface. References [1] C. Ashworth and M. Goodland. SSADM A practical approach. McGraw-Hill [2] L.L. Constantine and E. Yourdon. Structured Design. Prentice-Hall, [3] T. DeMarco. Structured Analysis and System Specification. Yourdon Press, [4] C. Gane and T. Sarson. Structured System Analysis. Prentice-Hall, [5] IEEE Transactions on Software Engineering 12(2), March [6] M. Jackson. System Development. Prentice-Hall, [7] SEI page on software architecture, architecture/. [8] A.I. Wasserman. User software engineering and the design of interactive information systems. Proc. 5th Intl. Conf. on Software Engineering. IEEE Press, [9] N. Wirth, Programming in Modula-2, 4th edition. Prentice-Hall,
Software Architecture and Design I
Software Architecture and Design I Instructor: Yongjie Zheng February 23, 2017 CS 490MT/5555 Software Methods and Tools Outline What is software architecture? Why do we need software architecture? How
More informationIntroduction to System Design
Introduction to System Design Software Requirements and Design CITS 4401 Lecture 8 System Design is a creative process no cook book solutions goal driven we create a design for solving some problem constraint
More informationRefresher: Lifecycle models. Lecture 22: Moving into Design. Analysis vs. Design. Refresher: different worlds. Analysis vs. Design.
Analysis vs. Design Why the distinction? Design Processes Logical vs. Physical Design System vs. Detailed Design Architectures System Architecture Software Architecture Architectural Patterns (next lecture)
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 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 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 informationSOFTWARE ENGINEERING. Lecture 6. By: Latifa ALrashed. Networks and Communication Department
1 SOFTWARE ENGINEERING Networks and Communication Department Lecture 6 By: Latifa ALrashed Outline q q q q q q q q Define the concept of the software life cycle in software engineering. Identify the system
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 informationModularity!! Guidelines for design! in any programming language!
Modularity!! Guidelines for design! in any programming language! 14-1! Modular Software! Software constructed as assemblies of small pieces! 14-2! Modular Software 2! Software constructed as assemblies
More informationMethods for requirements engineering
Methods for requirements engineering Objectives To explain the role of methods and techniques in requirements engineering To introduce data-flow modelling To introduce semantic data modelling To introduce
More informationSoftware Design. Software design is a blueprint or a plan for a computerbased solution for system
Software Design Software Design Software design is a blueprint or a plan for a computerbased solution for system Software design deals with transforming the customer requirements, as described by the SRS
More informationDEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS SOFTWARE ENGINEERING
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK TWO MARKS UNIT I SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering
More informationConceptual Model for a Software Maintenance Environment
Conceptual Model for a Software Environment Miriam. A. M. Capretz Software Engineering Lab School of Computer Science & Engineering University of Aizu Aizu-Wakamatsu City Fukushima, 965-80 Japan phone:
More informationLecturer: Sebastian Coope Ashton Building, Room G.18
Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 http://www.csc.liv.ac.uk/~pbell/comp201.html Lecture 13 Design
More informationContemporary Design. Traditional Hardware Design. Traditional Hardware Design. HDL Based Hardware Design User Inputs. Requirements.
Contemporary Design We have been talking about design process Let s now take next steps into examining in some detail Increasing complexities of contemporary systems Demand the use of increasingly powerful
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 informationModularity Guidelines for design in any programming language
Modularity Guidelines for design in any programming language 14-1 Modular Software Software constructed as assemblies of small pieces» Each piece encompasses the data and operations necessary to do one
More information10조 이호진 이지 호
10 조 200910045 이호진 200911415 이지호 According to the IEEE definition, design is.. The process of defining the architecture, components, interfaces, and other characteristics of a system or component 1.
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 informationIn his paper of 1972, Parnas proposed the following problem [42]:
another part of its interface. (In fact, Unix pipe and filter systems do this, the file system playing the role of the repository and initialization switches playing the role of control.) Another example
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 informationWhat is a Programming Paradigm
INTRODUCTION This chapter begins with brief discussion of various Programming paradigms that C++ supports i.e., procedural programming style, object based programming style and object oriented programming
More informationIntegration With the Business Modeler
Decision Framework, J. Duggan Research Note 11 September 2003 Evaluating OOA&D Functionality Criteria Looking at nine criteria will help you evaluate the functionality of object-oriented analysis and design
More informationSoftware Metrics and Design Principles. What is Design?
Software Metrics and Design Principles Chapters 5,8 What is Design? Design is the process of creating a plan or blueprint to follow during actual construction Design is a problem-solving activity that
More informationUNIT 1-SOFTWARE PROCESS AND PROJECT MANAGEMENT
PART A (2 MARKS) UNIT 1-SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering? Software engineering is a discipline in which theories, methods and tools are applied to develop professional
More informationTopics. Software Process. Agile. Requirements. Basic Design. Modular Design. Design Patterns. Testing. Quality. Refactoring.
CS310 - REVIEW Topics Process Agile Requirements Basic Design Modular Design Design Patterns Testing Quality Refactoring UI Design How these things relate Process describe benefits of using a software
More information.NET & Web Services. Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing. University of Teesside
.NET & Web Services Mike Lockyer, Gary Griffiths, Briony Oates, Barry Hebbron School of Computing Middlesbrough, TS1 3BA UK m.a.lockyer@tees.ac.uk ABSTRACT In this paper we present our current approach
More informationSoftware Architecture
Software Architecture Does software architecture global design?, architect designer? Overview What is it, why bother? Architecture Design Viewpoints and view models Architectural styles Architecture asssessment
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationChapter 9. Process Modeling. McGraw-Hill/Irwin. Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved.
Chapter 9 Process Modeling McGraw-Hill/Irwin Copyright 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Objectives Define systems modeling and differentiate logical and physical models. Define
More informationH&A Engineering. Systems
Introduction to Structured Methods The idea that system descriptions are more clear and easier with pictures rather than words provided the basis for the development of structured methods. Structured analysis
More informationComputer Aided Draughting and Design: Graded Unit 1
Higher National Graded Unit Specification General Information for Centres This Graded Unit has been validated as part of the HNC Computer Aided Draughting and Design (CADD) award. Centres are required
More informationINTERNAL ASSESSMENT TEST III Answer Schema
INTERNAL ASSESSMENT TEST III Answer Schema Subject& Code: Object-Oriented Modeling and Design (15CS551) Sem: V ISE (A & B) Q. No. Questions Marks 1. a. Ans Explain the steps or iterations involved in object
More informationThe Analysis and Proposed Modifications to ISO/IEC Software Engineering Software Quality Requirements and Evaluation Quality Requirements
Journal of Software Engineering and Applications, 2016, 9, 112-127 Published Online April 2016 in SciRes. http://www.scirp.org/journal/jsea http://dx.doi.org/10.4236/jsea.2016.94010 The Analysis and Proposed
More informationCS SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING CS 6403 - SOFTWARE ENGINEERING QUESTION BANK SIXTEEN MARKS 1. Explain iterative waterfall and spiral model for software life cycle and various activities
More informationCS560: Formal Modelling and Implementation of Systems (Term II)
CS560: Formal Modelling and Implementation of Systems (Term II) Software Design A.P.O Riordan, 2009 Email: a.oriordan@cs.ucc.ie Course Webpage: http://www.cs.ucc.ie/~adrian/cs560.html CS560 1 Design Design
More informationIntroduction to Assurance
Introduction to Assurance Overview Why assurance? Trust and assurance Life cycle and assurance April 1, 2015 Slide #1 Overview Trust Problems from lack of assurance Types of assurance Life cycle and assurance
More informationTHE BCS PROFESSIONAL EXAMINATION BCS Level 6 Professional Graduate Diploma in IT September 2017 EXAMINERS REPORT. Software Engineering 2
General Comments THE BCS PROFESSIONAL EXAMINATION BCS Level 6 Professional Graduate Diploma in IT September 2017 EXAMINERS REPORT Software Engineering 2 The pass rate was 40% representing the lowest mark
More informationCS6403 SOFTWARE ENGINEERING Year / Sem : II / IV Sub. Code &Subject : CS6403 SOFTWARE ENGINEERING QUESTION BANKWITH ANSWERS
CS6403 SOFTWARE ENGINEERING Year / Sem : II / IV Sub. Code &Subject : CS6403 SOFTWARE ENGINEERING QUESTION BANKWITH ANSWERS UNIT 1-SOFTWARE PROCESS AND PROJECT MANAGEMENT 1. What is software engineering?
More informationCOSC 3351 Software Design. Software Design Methodology. Edgar Gabriel. Spring Outline
COSC 3351 Software Design Software Design Methodology Spring 2008 Outline Causes of difficulties in software design Vehicles to overcome difficulties Various strategies to solve software design problems
More informationCreating a Lattix Dependency Model The Process
Creating a Lattix Dependency Model The Process Whitepaper January 2005 Copyright 2005-7 Lattix, Inc. All rights reserved The Lattix Dependency Model The Lattix LDM solution employs a unique and powerful
More informationManaging Change and Complexity
Managing Change and Complexity The reality of software development Overview Some more Philosophy Reality, representations and descriptions Some more history Managing complexity Managing change Some more
More informationAns 1-j)True, these diagrams show a set of classes, interfaces and collaborations and their relationships.
Q 1) Attempt all the following questions: (a) Define the term cohesion in the context of object oriented design of systems? (b) Do you need to develop all the views of the system? Justify your answer?
More informationStandards Readiness Criteria. Tier 2
Document Number: HITSP 06 N 85 Date: June 1, 2006 Standards Readiness Criteria Tier 2 Version 1.0 May 12, 2006 HITSP Standards Harmonization Committee V 1.0 (5/12/2006) 1 Introduction...3 Background Information...3
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 informationStructured Analysis and Structured Design
Structured Analysis and Structured Design - Introduction to SASD - Structured Analysis - Structured Design Ver. 1.5 Lecturer: JUNBEOM YOO jbyoo@konkuk.ac.kr http://dslab.konkuk.ac.kr References Modern
More informationWHAT IS SOFTWARE ARCHITECTURE?
WHAT IS SOFTWARE ARCHITECTURE? Chapter Outline What Software Architecture Is and What It Isn t Architectural Structures and Views Architectural Patterns What Makes a Good Architecture? Summary 1 What is
More informationis easing the creation of new ontologies by promoting the reuse of existing ones and automating, as much as possible, the entire ontology
Preface The idea of improving software quality through reuse is not new. After all, if software works and is needed, just reuse it. What is new and evolving is the idea of relative validation through testing
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 informationTest and Evaluation of Autonomous Systems in a Model Based Engineering Context
Test and Evaluation of Autonomous Systems in a Model Based Engineering Context Raytheon Michael Nolan USAF AFRL Aaron Fifarek Jonathan Hoffman 3 March 2016 Copyright 2016. Unpublished Work. Raytheon Company.
More informationTutorial 1 Answers. Question 1
Tutorial 1 Answers Question 1 Complexity Software in it what is has to do, is often essentially complex. We can think of software which is accidentally complex such as a large scale e-commerce system (simple
More informationAN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL. Fiona Rohde. Department of Commerce The University of Queensland, 4072.
AN ONTOLOGICAL EVALUATION OF JACKSON'S SYSTEM DEVELOPMENT MODEL Fiona Rohde Department of Commerce The University of Queensland, 4072. Australia ABSTRACT Within the discipline of information systems, numerous
More informationSOME TYPES AND USES OF DATA MODELS
3 SOME TYPES AND USES OF DATA MODELS CHAPTER OUTLINE 3.1 Different Types of Data Models 23 3.1.1 Physical Data Model 24 3.1.2 Logical Data Model 24 3.1.3 Conceptual Data Model 25 3.1.4 Canonical Data Model
More informationMULTIPLE CHOICE. Choose the one alternative that best completes the statement or answers the question.
Exam Name MULTIPLE CHOICE. Choose the one alternative that best completes the statement or answers the question. 1) A process has a: 1) A) pronoun label B) noun phrase label C) verb phrase label D) adjective
More information3rd Lecture Languages for information modeling
3rd Lecture Languages for information modeling Agenda Languages for information modeling UML UML basic concepts Modeling by UML diagrams CASE tools: concepts, features and objectives CASE toolset architecture
More informationiserver Free Archimate ArchiMate 1.0 Template Stencil: Getting from Started Orbus Guide Software Thanks for Downloading the Free ArchiMate Template! Orbus Software have created a set of Visio ArchiMate
More informationSystem Name Software Architecture Description
System Name Software Architecture Description Author Name Contact Details Version Date template 2011 Eoin Woods & Nick Rozanski 1 / 25 1. Version History Version Date Author Comments 1 July 08 Eoin Woods
More informationSoftware Development Chapter 1
Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic
More informationChartered Membership: Professional Standards Framework
Chartered Membership: Professional Standards Framework Foreword The Chartered Institute of Architectural Technologists (CIAT) is the lead professional body for Architectural Technology and the UK Competent
More informationFunctional Modeling with Data Flow Diagrams
Functional Modeling with Data Flow Diagrams Amasi Elbakush 5771668 Teaching Assistant : Daniel Alami Utrecht University 1 Introduction Data Flow Diagrams (DFDs) are a visual representation of the flow
More informationIntroduction to Object Oriented Analysis and Design
A class note on Introduction to Object Oriented Analysis and Design Definition In general, analysis emphasizes an investigation of the problem and requirements of the domain, rather than a solution. Whereas,
More informationChapter 8 Visualization and Optimization
Chapter 8 Visualization and Optimization Recommended reference books: [1] Edited by R. S. Gallagher: Computer Visualization, Graphics Techniques for Scientific and Engineering Analysis by CRC, 1994 [2]
More informationThe Open Group SOA Ontology Technical Standard. Clive Hatton
The Open Group SOA Ontology Technical Standard Clive Hatton The Open Group Releases SOA Ontology Standard To Increase SOA Adoption and Success Rates Ontology Fosters Common Understanding of SOA Concepts
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 informationA CELLULAR, LANGUAGE DIRECTED COMPUTER ARCHITECTURE. (Extended Abstract) Gyula A. Mag6. University of North Carolina at Chapel Hill
447 A CELLULAR, LANGUAGE DIRECTED COMPUTER ARCHITECTURE (Extended Abstract) Gyula A. Mag6 University of North Carolina at Chapel Hill Abstract If a VLSI computer architecture is to influence the field
More informationLecture 19 Engineering Design Resolution: Generating and Evaluating Architectures
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
More informationSoftware Design. Levels in Design Process. Design Methodologies. Levels..
Design Software Design Design activity begins with a set of requirements Design done before the system is implemented Design is the intermediate language between requirements and code Moving from problem
More informationSafety Case Composition Using Contracts - Refinements based on Feedback from an Industrial Case Study
Safety Case Composition Using Contracts - Refinements based on Feedback from an Industrial Case Study Jane Fenn and Richard Hawkins BAE SYSTEMS, Brough, UK Phil Williams General Dynamics (United Kingdom)
More informationProgramming II. Modularity 2017/18
Programming II Modularity 2017/18 Module? Lecture Outline Evolution and history of programming languages Modularity Example History of Programming Programming Paradigms How and why languages develop? How
More informationCSCU9T4: Managing Information
CSCU9T4: Managing Information CSCU9T4 Spring 2016 1 The Module Module co-ordinator: Dr Gabriela Ochoa Lectures by: Prof Leslie Smith (l.s.smith@cs.stir.ac.uk) and Dr Nadarajen Veerapen (nve@cs.stir.ac.uk)
More informationAn Efficient Methodology for Developing and Maintaining Consistent Software Using OOAD Tools
An Efficient Methodology for Developing and Maintaining Consistent Software Using OOAD Tools S. Pasupathy 1, Dr. R. Bhavani 2 Associate Professor, Dept. of CSE, FEAT, Annamalai University, Tamil Nadu,
More informationModule B1 An Introduction to TOGAF 9.1 for those familiar with TOGAF 8
Informs the capability Ensures Realization of Business Vision Business needs feed into method Refines Understanding Informs the Business of the current state Sets targets, KPIs, budgets for architecture
More informationUX Research in the Product Lifecycle
UX Research in the Product Lifecycle I incorporate how users work into the product early, frequently and iteratively throughout the development lifecycle. This means selecting from a suite of methods and
More informationSoftware Architecture
Software Architecture Good software architecture makes the rest of the project easy. Steve McConnell, Survival Guide There are two ways of constructing a software design: one way is to make it so simple
More informationFORMALIZED SOFTWARE DEVELOPMENT IN AN INDUSTRIAL ENVIRONMENT
FORMALIZED SOFTWARE DEVELOPMENT IN AN INDUSTRIAL ENVIRONMENT Otthein Herzog IBM Germany, Dept. 3100 P.O.Box 80 0880 D-7000 STUTTGART, F. R. G. ABSTRACT tn the IBM Boeblingen Laboratory some software was
More informationThe Design Space of Software Development Methodologies
The Design Space of Software Development Methodologies Kadie Clancy, CS2310 Term Project I. INTRODUCTION The success of a software development project depends on the underlying framework used to plan and
More informationArchitecture CSE 403. Fallingwater by Frank Lloyd Wright
Architecture CSE 403 Fallingwater by Frank Lloyd Wright Outline What is a software architecture? What does an architecture look like? What is a good architecture? Properties of architectures Example architectures
More informationLecture 34 SDLC Phases and UML Diagrams
That Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur Lecture 34 SDLC Phases and UML Diagrams Welcome
More informationSystem Development Life Cycle Methods/Approaches/Models
Week 11 System Development Life Cycle Methods/Approaches/Models Approaches to System Development System Development Life Cycle Methods/Approaches/Models Waterfall Model Prototype Model Spiral Model Extreme
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 informationSoftware Engineering Prof.N.L.Sarda IIT Bombay. Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II)
Software Engineering Prof.N.L.Sarda IIT Bombay Lecture-11 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue our discussion on process modeling. In the previous lecture
More informationEngineering Design Notes I Introduction. EE 498/499 Capstone Design Classes Klipsch School of Electrical & Computer Engineering
Engineering Design Notes I Introduction EE 498/499 Capstone Design Classes Klipsch School of Electrical & Computer Engineering Topics Overview Analysis vs. Design Design Stages Systems Engineering Integration
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 informationSoftware Engineering Principles
1 / 19 Software Engineering Principles Miaoqing Huang University of Arkansas Spring 2010 2 / 19 Outline 1 2 3 Compiler Construction 3 / 19 Outline 1 2 3 Compiler Construction Principles, Methodologies,
More informationApplying ISO/IEC Quality Model to Quality Requirements Engineering on Critical Software
Applying ISO/IEC 9126-1 Quality Model to Quality Engineering on Critical Motoei AZUMA Department of Industrial and Management Systems Engineering School of Science and Engineering Waseda University azuma@azuma.mgmt.waseda.ac.jp
More informationStandard Glossary of Terms used in Software Testing. Version 3.2. Foundation Extension - Usability Terms
Standard Glossary of Terms used in Software Testing Version 3.2 Foundation Extension - Usability Terms International Software Testing Qualifications Board Copyright Notice This document may be copied in
More informationQualification Specification. Higher Apprenticeship in Business & Professional Administration Level 4 (England)
Qualification Specification Higher Apprenticeship in Business & Professional Administration Level 4 (England) Version 3.0 (October 2017) Qualification Specification: Business Administration: Higher Apprenticeship
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 informationQualification Specification for the Knowledge Modules that form part of the BCS Level 4 Software Developer Apprenticeship
Qualification Specification for the Knowledge Modules that form part of the BCS Level 4 Software Developer Apprenticeship BCS Level 4 Diploma in Software Development Methodologies BCS Level 4 Diploma in
More informationLECTURE 3: SOFTWARE DESIGN. Software Engineering Mike Wooldridge
LECTURE 3: SOFTWARE DESIGN Mike Wooldridge 1 Design Computer systems are not monolithic: they are usually composed of multiple, interacting modules. Modularity has long been seen as a key to cheap, high
More informationTransformation of analysis model to design model
2010 International Conference on E-business, Management and Economics IPEDR vol.3 (2011) (2011) IACSIT Press, Hong Kong Transformation of analysis model to design model Lalji Prasad Truba College of Engineering
More informationEvidence-based Development coupling structured argumentation with requirements development.
Evidence-based Development coupling structured argumentation with requirements development Jeremy.Dick@integrate.biz integrate 2012 based on paper Paper: EVIDENCE-BASED DEVELOPMENT COUPLING STRUCTURED
More informationSeng 480b/CSC 586b Building Web Applications
Seng 480b/CSC 586b Building Web Applications Daniel M. German Department of Computer Science University of Victoria 1 SEng 480b dmgerman@uvic.ca What this course is and it is not about It is not about:
More informationDarshan Institute of Engineering & Technology for Diploma Studies
REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all
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 informationCSC Advanced Object Oriented Programming, Spring Overview
CSC 520 - Advanced Object Oriented Programming, Spring 2018 Overview Brief History 1960: Simula first object oriented language developed by researchers at the Norwegian Computing Center. 1970: Alan Kay
More informationIntroducing MESSIA: A Methodology of Developing Software Architectures Supporting Implementation Independence
Introducing MESSIA: A Methodology of Developing Software Architectures Supporting Implementation Independence Ratko Orlandic Department of Computer Science and Applied Math Illinois Institute of Technology
More information21. Document Component Design
Page 1 of 17 1. Plan for Today's Lecture Methods for identifying aggregate components 21. Document Component Design Bob Glushko (glushko@sims.berkeley.edu) Document Engineering (IS 243) - 11 April 2005
More informationChapter 4 Objectives
Chapter 4 Objectives Eliciting requirements from the customers Modeling requirements Reviewing requirements to ensure their quality Documenting requirements for use by the design and test teams 4.1 The
More informationTINA-CAT WorkGroup Request For Proposals
TINA-CAT WorkGroup Request For Proposals TINA Conformance Testing Framework Document information Title: TINA Conformance Testing Framework RfP Version: 1.0: Approved and Released Date: July 19, 1999 1.
More information