MeDUSA Method for Designing UML2-based Embedded System Software Architectures
|
|
- Howard Williams
- 6 years ago
- Views:
Transcription
1 MeDUSA Method for Designing UML2-based Embedded System Software Architectures Alexander Nyßen 1, Horst Lichter 1, Jan Suchotzki 2, Lukas Kurmann 3 1 Introduction MeDUSA (Method for Designing UML2-based Embedded System Software Architectures) is a model-driven software design method targeting the domain of small embedded systems. It was developed by the Research Group Software Construction of the RWTH Aachen in close cooperation with the German ABB Research Centre in Ladenburg. MeDUSA incorporates various practical experiences gained during the industrial development of embedded software in ABB Business Unit Instrumentation. Regarding its applicability, the domain covered by MeDUSA can be characterized, as stated above, as software development of small embedded devices. However, as this application domain is rather broad and even if we think that MeDUSA would be applicable to quite a lot of its different sub domains understanding the method and its characteristics can be best achieved by taking into consideration the domain MeDUSA was initially developed for, namely that of software development for field devices. Field devices are rather small embedded systems that are integrated into an often large process automation plant. They are used across various industries such as food, chemicals, water and waste water, oil and gas, pharmaceutical, and others. Most of them occur in many different variants. Measurement devices for example, which are one sub category of field devices, occur in different product variants concerning the physical quantity they measure (temperature, pressure, flow), the measure principle applied, the communication capabilities offered, as well as the safety and reliability constraints accomplished. 2 Requirements and Objectives All field devices do have in common that they can be characterized by rather strong resource constraints regarding memory, power consumption, and computing time. Thus, object-oriented programming languages are not yet the first choice and C is still the main implementation language in the regarded application domain. Any design method being applicable to the domain should therefore allow a smooth and rather direct transition from a detailed design into a procedural implementation in the C-language. The large extend of variety, field devices occur in, does precipitate that the development of them is done or is at least intended to be done in a product line approach. The software of most measurement devices is for example developed on top of a common product unspecific platform covering basic services and hardware interfaces, into which product specific components regarding the measurement task, which is strongly dependent on the physical quantity to measure as well as on the measurement principle applied, have to be integrated. A method supporting the development of software for such devices should therefore be capable of supporting distributed development of software components, so that platform as well as product specific components can be developed in a distributed manner and can then be easily integrated.
2 The last basic requirement posed on any method targeting the regarded application domain is, that the notation employed is not proprietary but best based on a standard or at least industry standard. There are several reasons for this. First the development of software for safety critical application areas requires the application of standards wherever possible. Second, the application of a standard best enables the communication in a distributed development organization (as we focus in ABB Business Unit Instrumentation), as training of developers can be easily achieved. Last, a large number of standard-conformant tools is available from which a selection can be made when assembling a tooling infrastructure. Having all that in mind, our intention was to develop a design method that fulfills all those requirements while also considering the expectations and practical experience of application developers. Having already gained practical experience with the application of the objectoriented COMET method [Go00] in the domain [NM04], we regarded it to be an adequate starting point. Thus MeDUSA tries to transfer all of COMET s advantages to the regarded application domain while trying to expunge the most of its shortcomings identified during its practical application. 3 The MeDUSA Workflow MeDUSA covers the software development life cycle from the early requirements modeling, via analysis and architectural design, up to detailed design modeling as shown in Figure 1. It supports the model-driven paradigm by a systematic and intense use of models through all those steps. Figure 1: MeDUSA workflow overview 3.1 Requirements Modeling During requirements modeling, functional requirements of the software system are captured in terms of use cases. Besides graphical modeling based on the UML, a major focus is also spent on developing narrative use case descriptions to capture the detailed flow of events of each use case, as well as pre- and post-conditions or other important information. Although use case modeling is only partly suited to capture non-functional requirements, the context of real-time systems requires that some of them - especially timing constraints - have to be already regarded during this early step. That is why MeDUSA adopts the concept of timer actors, introduced by the COMET method, to capture non-functional timing constraints during use case modeling.
3 3.2 Analysis Modeling During analysis modeling, the problem domain is regarded. Analogous to COMET, a system context model is first developed that captures the system s environment (or more precise the internal interfaces to that environment) in terms of interface and timer objects. Subsequently a system information model is then developed, which captures the relevant long living application data in terms of entity objects. In contrast to COMET, where both models are recorded in terms of static class diagrams, MeDUSA makes use of object (instance) diagrams in this step, as this facilitates the intuitive understanding of the developers in the targeted domain. While the two initial steps of the analysis phase - system context and system information modeling - deal with identifying interface, timer and entity objects, adjacent analysis steps of the analysis phase deal with the identification of further analysis objects (control and application logic) in order to gain a complete analysis model. The identification process is supported by applying object structuring criteria, which were with slight modifications adopted from the COMET method. In detail, missing control and application logic objects are identified by modeling an object collaboration for each identified use case, so that the inter-object behavior of the collaboration jointly reaches the goal of the use case. Last, the internal object behavior is then modeled for those control and application logic objects that possess non-trivial behavior. 3.3 Architectural Design Modeling After having understood the problem domain in terms of analysis objects, whose internal and external behavior have been captured, architectural design modeling is the first step of composing a solution. Here, identifying subsystems by grouping together functionally dependent analysis objects is the starting point. It is similar to the identification of objects during analysis modeling supported by taking into consideration subsystem structuring criteria, which were adopted from COMET. After that, the structural and behavioral relationships between the identified subsystems have to be regarded, in order to design the structural and behavioral aspects of the interfaces between them. In contrast to COMET, where a class and a consolidated collaboration diagram are employed to model the architectural design on the system level, MeDUSA uses component (respectively composite structure) and sequence diagrams for this purpose. A component diagram in the form of a composite structure diagram is best suited to model the top-level runtime structure of the system in terms of interconnected subsystems. Sequence diagrams are well suited to describe the behavioral relationships between subsystems as they are far more expressive than collaboration diagrams and thus allow to model not only a main flow of events, but also all facets of alternative flows. In contrast to COMET, where the internal decomposition of each subsystem is also regarded during this step by using a collaboration and a class diagram to demonstrate the internal decomposition of each subsystem in terms of objects and related classes, MeDUSA does not regard the internal details of each subsystem during architectural design. They are regarded not earlier than during detailed design. The reason for this is that MeDUSA was designed to allow the distributed and independent design of each subsystem (something that was motivated by the distributed organization structure of the ABB Business Unit Instrumentation). Therefore the decomposition of the system into subsystems and the structural and behavioral relationships between those subsystems are regarded during architectural design, to assure that a postponed integration of the separately designed subsystems can be achieved.
4 3.4 Detailed Design Modeling After having identified subsystems and after having defined their structural and behavioral relationships during architectural design, the focus is then placed on designing the internal decomposition of each subsystem. That is, the initial object collaboration that has been grouped together to form the subsystem during early architectural design modeling is now consolidated and enriched. At the end, a detailed decomposition of each subsystem into design objects (or components in terms of more complex subsystems) has to be found, which cooperatively perform to deliver the services offered by the subsystems via its interfaces. Next this internal decomposition has to be analyzed concerning concurrency issues. That is, active objects have to be identified and transferred into tasks. The initial task design then has to be optimized, as the number of tasks has to be removed to a reasonable amount. This step is supported by the task structuring criteria adopted from the COMET method. Last, the detailed class design has to be developed for all active and passive design objects that are part of a subsystem s decomposition (for those objects that are used as parameters in a provided or required interface of a subsystem, the classifier design has already been done during architectural design to ensure that the separately developed subsystems can be well integrated). It has to be pointed out that, not earlier than during this step, the transition from objects to classifiers is done for all objects that form the internal subsystem decomposition something that we describe as the characteristic of the method to be instance-driven. We will come back to this in the next section. 4 Characteristics of MeDUSA Acting on the maxim that model-driven development for small embedded systems should allow a seamless transition from the design model to an implementation in the C-language MeDUSA was - unlike COMET - designed to be an object-based rather than an objectoriented method. That is inheritance and polymorphism are disregarded until the late detailed design, as the conception of classifiers is done not earlier than during this step (to be precise this holds for all objects forming the internal decomposition of a subsystem, as stated above). The application of object-oriented concepts is not enforced during earlier steps of the method. Therefore those concepts may even be omitted during detailed design to allow a more straightforward implementation of the detailed design model. Taking into consideration that the run-time structure of software systems in the regarded domain is mostly rather small - being comprised of only a few subsystems and a manageable amount of objects - MeDUSA was designed to be an instance-driven method. That is, during all steps of the method, from the early analysis up to the late detailed design, the modeling of objects (or more precise classifier instances) rather than the modeling of classifiers is enforced. This allows the architectural design of the system to be directly captured in terms of the system s run-time structure rather in an abstracted classifier-based view on it and does - according to our practical experience - accommodate the intuitive understanding of the application designers and developers. Due to the fact that the main focus of the method resides on modeling the run-time structure of the system rather than modeling the static classifier structure, the enhancements and additions the UML introduced with its new standard version 2 are quite beneficial [NL05]. The newly introduced composite structure diagrams for example are very well suited to cover the runtime structure of a system s subsystems. Because of this and because of the tool landscape which is currently shifting to the new standard release - MeDUSA was conceptually designed to employ the latest UML version as its notation.
5 5 Lessons Learned MeDUSA was of course developed in several iterations. Although we tried to include representatives from different development teams of ABB Business Unit Instrumentation already into the development of the initial version of the method, the result did not yet fulfill the developers needs to all extend so that several changes from which some were also of major kind - had to be applied. Most of these changes however even including a redesign of the method to obtain its instance-driven nature were introduced already in the first revision of the method. It was developed after the method had been established for about 10 months so that enough experience from its practical application had been gained. Especially the coaching of developers by MeDUSA introduction workshops and guided analysis & design sessions during the introduction phase of the method gave a great insight into the problems, the first version still had. Additionally a job rotation of one of the method developers from ABB Research Centre into a development site applying the new method was a key success factor for its acceptance and improvement. One of the most important lessons learned from our viewpoint therefore is that developing and introducing a new design method does indeed take - first and foremost - time. Even if the method is developed in a very systematic manner, and even if its users are involved in the development process very close and right from the beginning, enough time to gain experience and learn from applying the method in practice simply has to be taken. Also, it has to be assured that the people having to apply the method are willing to learn and that their anxieties and obscurities are eliminated. A good means to achieve this is to offer extensive coaching and to establish a transparent direct feedback loop. 6 Conclusion and Outlook We tried to create a method that suits the special needs of software development for small embedded systems. As C is still the main implementation language in the targeted domain, and as a smooth transition from detailed design to implementation is essential for the success of a model-driven development approach, we decided to create an object-based rather than an object-oriented method. The manageable complexity of the regarded software systems does allow to model their run-time structure directly. This is what led us to equip the method with what we call its instance-driven nature. That is, up to the late detailed design, instances rather than classifiers are modelled. We hope that both of these outstanding characteristics help to better support the development of systems in the targeted domain. At least in ABB Business Unit Instrumentation we retrieved strong evidence that this might be the case. The full benefit of a model-driven method like MeDUSA can of course only be unleashed if its application is supported by adequate tools. Although one can choose from a broad variety of available modeling tools, as the method is based on the UML2 standard, we noticed that none of these does indeed support MeDUSA s notation subset to all extend. Actually we did not find a single modeling tool that could be characterized as being fully UML2 standard conformant. Best possible support for MeDUSA can therefore only be achieved by using a customized modeling tool, which fully supports the notation used by MeDUSA and which also offers automated code generation to allow a direct transition from design to code. Therefore we are currently spending a lot of effort in this direction.
6 Besides that we are currently investigating to adapt MeDUSA to make it best suitable for a product-line engineering approach. While distributed development of reusable components based on a common architecture is already done based on MeDUSA, the method has still to be enhanced to offer support for dealing with the variability that occurs in a product-line context. That is, modeling support for variability has to be introduced to the different UML2 diagram types employed by MeDUSA and the different objectives and requirements of domain and application engineering have to be reflected by MeDUSA s methodology. Although MeDUSA was initially designed targeting the rather narrow domain of field devices, we think that it might be applicable to the development of quite a broad range of small embedded systems. We still have to supply the evidence for this. However, a small indication might be that other business units of ABB are currently planning to introduce MeDUSA for their development as well. Literature [Go00] Gomaa, Hassan: Designing Concurrent, Distributed, and Real-Time Applications with UML. Object Technology Series, Addison Wesley, [NM04] Nyßen, Alexander; Müller, Peter; Suchotzki, Jan; Lichter, Horst: Erfahrungen bei der systematischen Entwicklung kleiner eingebetteter Systeme mit der COMET- Methode. in Hesse, Rumpe (Hrg.), Lecture Notes in Informatics (LNI) Modellierung 2004, Marburg, Volume P-45, p [NL05] Nyßen, Alexander; Lichter, Horst; Suchotzki, Jan; Müller, Peter; Stelter, Andreas: UML2-basierte Architekturmodellierung kleiner eingebetteter Systeme Erfahrungen einer Feldstudie. in Klein, Rumpe, Schätz (Hrg.), Tagungsband des Dagstuhl-Workshops Modellbasierte Entwicklung eingebetteter Systeme (MBEES), Technischer Bericht, TU Braunschweig, TUBS-SSE , RWTH Aachen, Research Group Software Construction {any lichter}@cs.rwthaachen.de 2 ABB Automation GmbH, D Minden, jan.suchotzki@de.abb.com 3 ABB Corporate Research, D Ladenburg, lukus.kurmann@de.abb.com
A Model-Based Development Method for Device Drivers
A Model-Based Development Method for Device Drivers Michael Kersten Siemens AG Otto-Hahn-Ring 6 D-81739 München Ulrich Margull 1 mal 1 Software GmbH Maxstr. 31 D-90762 Fürth Nikolaus Regnat Siemens AG
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 informationAn Approach to Software Component Specification
Page 1 of 5 An Approach to Software Component Specification Jun Han Peninsula School of Computing and Information Technology Monash University, Melbourne, Australia Abstract. Current models for software
More informationTowards Systematic Usability Verification
Towards Systematic Usability Verification Max Möllers RWTH Aachen University 52056 Aachen, Germany max@cs.rwth-aachen.de Jonathan Diehl RWTH Aachen University 52056 Aachen, Germany diehl@cs.rwth-aachen.de
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 informationTaming Rave: How to control data collection standards?
Paper DH08 Taming Rave: How to control data collection standards? Dimitri Kutsenko, Entimo AG, Berlin, Germany Table of Contents Introduction... 1 How to organize metadata... 2 How to structure metadata...
More informationTITUS A Graphical Design Methodology for Embedded Automotive Software
TITUS A Graphical Design Methodology for Embedded Automotive Software Ulrich Freund, Alexander Burst, ETAS GmbH Stuttgart Abstract Vehicle body electronic software has reached a level of complexity and
More informationLecture Notes UML UNIT-II. Subject: OOAD Semester: 8TH Course No: CSE-802
UNIT-II Lecture Notes On UML IMPORTANCE OF MODELING, BRIEF OVERVIEW OF OBJECT MODELING TECHNOLOGY (OMT) BY RAMBAUGH, BOOCH METHODOLOGY, USE CASE DRIVE APPROACH (OOSE) BY JACKOBSON. KHALID AMIN AKHOON 1
More informationMODELLING COMPOSITIONS OF MODULAR EMBEDDED SOFTWARE PRODUCT LINES
MODELLING COMPOSITIONS OF MODULAR EMBEDDED SOFTWARE PRODUCT LINES Wolfgang Friess AUDI AG wolfgang.friess@audi.de Julio Sincero University Erlangen-Nuernberg sincero@informatik.uni-erlangen.de Wolfgang
More informationThe Analysis and Design of the Object-oriented System Li Xin 1, a
International Conference on Materials Engineering and Information Technology Applications (MEITA 2015) The Analysis and Design of the Object-oriented System Li Xin 1, a 1 Shijiazhuang Vocational Technology
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based
More informationSoftware Service Engineering
Software Service Engineering Lecture 4: Unified Modeling Language Doctor Guangyu Gao Some contents and notes selected from Fowler, M. UML Distilled, 3rd edition. Addison-Wesley Unified Modeling Language
More informationIntroduction to IRQA 4
Introduction to IRQA 4 Main functionality and use Marcel Overeem 1/7/2011 Marcel Overeem is consultant at SpeedSoft BV and has written this document to provide a short overview of the main functionality
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 informationPattern-Based Architectural Design Process Model
Pattern-Based Architectural Design Process Model N. Lévy, F. Losavio Abstract: The identification of quality requirements is crucial to develop modern software systems, especially when their underlying
More informationChapter : Analysis Modeling
Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints
More information06. Analysis Modeling
06. Analysis Modeling Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Overview of Analysis Modeling 1 Requirement Analysis 2 Analysis Modeling Approaches
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 informationSoftware Engineering
Software Engineering A systematic approach to the analysis, design, implementation and maintenance of software. Software Development Method by Jan Pettersen Nytun, page 1 Software Engineering Methods Most
More informationRequirements and Design Overview
Requirements and Design Overview Robert B. France Colorado State University Robert B. France O-1 Why do we model? Enhance understanding and communication Provide structure for problem solving Furnish abstractions
More informationCS:2820 (22C:22) Object-Oriented Software Development
The University of Iowa CS:2820 (22C:22) Object-Oriented Software Development! Spring 2015 Software Complexity by Cesare Tinelli Complexity Software systems are complex artifacts Failure to master this
More informationElevator Control System
Control System Koichiro Ochimizu School of Information Science Japan Advanced Institute of Science and Technology Schedule(3/3) March 2 3:00 Unified Process and COMET 4:30 Case Study of Control System
More informationDomain Engineering And Variability In The Reuse-Driven Software Engineering Business.
OBM 7 -draft 09/02/00 1 Domain Engineering And Variability In The Reuse-Driven Software Engineering Business. Martin L. Griss, Laboratory Scientist, Hewlett-Packard Laboratories, Palo Alto, CA. Effective
More informationSOFTWARE MODELING AND DESIGN. UML, Use Cases, Patterns, and. Software Architectures. Ki Cambridge UNIVERSITY PRESS. Hassan Gomaa
SOFTWARE MODELING AND DESIGN UML, Use Cases, Patterns, and Software Architectures Hassan Gomaa George Mason University, Fairfax, Virginia Ki Cambridge UNIVERSITY PRESS Contents Preface P"U
More informationEvaluating OO-CASE tools: OO research meets practice
Evaluating OO-CASE tools: OO research meets practice Danny Greefhorst, Matthijs Maat, Rob Maijers {greefhorst, maat, maijers}@serc.nl Software Engineering Research Centre - SERC PO Box 424 3500 AK Utrecht
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 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 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 informationSOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.
SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented
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 informationObject-oriented Compiler Construction
1 Object-oriented Compiler Construction Extended Abstract Axel-Tobias Schreiner, Bernd Kühl University of Osnabrück, Germany {axel,bekuehl}@uos.de, http://www.inf.uos.de/talks/hc2 A compiler takes a program
More informationFunctional Design of Web Applications. (partially, Chapter 7)
Functional Design of Web Applications (partially, Chapter 7) Functional Design: An Overview Users of modern WebApps expect that robust content will be coupled with sophisticated functionality The advanced
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 informationComparative Analysis of Architectural Views Based on UML
Electronic Notes in Theoretical Computer Science 65 No. 4 (2002) URL: http://www.elsevier.nl/locate/entcs/volume65.html 12 pages Comparative Analysis of Architectural Views Based on UML Lyrene Fernandes
More informationSRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A
SRI VENKATESWARA COLLEGE OF ENGINERRING AND TECHNOLOGY THIRUPACHUR,THIRUVALLUR UNIT I OOAD PART A 1. What is an object? An object is a combination of data and logic; the representation of some realworld
More informationMetadata in the Driver's Seat: The Nokia Metia Framework
Metadata in the Driver's Seat: The Nokia Metia Framework Abstract Patrick Stickler The Metia Framework defines a set of standard, open and portable models, interfaces, and
More informationObject-Oriented Systems Development: Using the Unified Modeling Language
Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 4: Object-Oriented Methodologies Goals Object-Oriented Methodologies The Rumbaugh et al. OMT The Booch methodology Jacobson's
More informationSoftware Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.
Software Design Patterns Jonathan I. Maletic, Ph.D. Department of Computer Science Kent State University J. Maletic 1 Background 1 Search for recurring successful designs emergent designs from practice
More informationModeling Crisis Management System With the Restricted Use Case Modeling Approach
Modeling Crisis Management System With the Restricted Use Case Modeling Approach Gong Zhang 1, Tao Yue 2, and Shaukat Ali 3 1 School of Computer Science and Engineering, Beihang University, Beijing, China
More informationINTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2
INTRODUCING A MULTIVIEW SOFTWARE ARCHITECTURE PROCESS BY EXAMPLE Ahmad K heir 1, Hala Naja 1 and Mourad Oussalah 2 1 Faculty of Sciences, Lebanese University 2 LINA Laboratory, University of Nantes ABSTRACT:
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 informationSample Exam. Advanced Test Automation - Engineer
Sample Exam Advanced Test Automation - Engineer Questions ASTQB Created - 2018 American Software Testing Qualifications Board Copyright Notice This document may be copied in its entirety, or extracts made,
More informationObject-Oriented Systems Analysis and Design Using UML
10 Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design, 8e Kendall & Kendall Copyright 2011 Pearson Education, Inc. Publishing as Prentice Hall Learning Objectives Understand
More informationObject-oriented development. Object-oriented Design. Objectives. Characteristics of OOD. Interacting objects. Topics covered
Object-oriented development Object-oriented Design Object-oriented analysis, design and programming are related but distinct. OOA is concerned with developing an object model of the application domain.
More informationDomain Mapping for Product-line Requirements
Computer Science Technical Reports Computer Science 2004 Domain Mapping for Product-line Requirements Kendra Schmid Iowa State University Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports
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 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 informationA Role-based Use Case Model for Remote Data Acquisition Systems *
A Role-based Use Case Model for Remote Acquisition Systems * Txomin Nieva, Alain Wegmann Institute for computer Communications and Applications (ICA), Communication Systems Department (DSC), Swiss Federal
More informationImproving System Usability Through the Automation of User's Routine Intentions: an Image Edition Tool Case Study
Improving System Usability Through the Automation of User's Routine Intentions: an Image Edition Tool Case Study Alejandro C. Frery, André R. G. do A. Leitão, André W. B. Furtado, Fernando da C. A. Neto,
More informationArchiMate 2.0. Structural Concepts Behavioral Concepts Informational Concepts. Business. Application. Technology
ArchiMate Core Structural Concepts Behavioral Concepts Informational Concepts interaction Technology Application Layer Concept Description Notation Concept Description Notation Actor An organizational
More informationA STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN
A STUDY OF OBJECT ORIENTED ANALYSIS AND DESIGN GARJE RAKESH RAMESHRAO RESEARCH SCHOLAR, DEPT. OF COMPUTER SCIENCE CMJ UNIVERSITY, SHILLONG, MEGHALAYA INTRODUCTION Object-oriented Analysis and Design is
More informationView-Based Modeling of Function Nets
View-Based Modeling of Function Nets Hans Grönniger 1, Jochen Hartmann 2, Holger Krahn 1, Stefan Kriebel 2, and Bernhard Rumpe 1 1 Institut für Software Systems Engineering, TU Braunschweig, Germany 2
More informationSpemmet - A Tool for Modeling Software Processes with SPEM
Spemmet - A Tool for Modeling Software Processes with SPEM Tuomas Mäkilä tuomas.makila@it.utu.fi Antero Järvi antero.jarvi@it.utu.fi Abstract: The software development process has many unique attributes
More informationSWE 760 Lecture 1: Introduction to Analysis & Design of Real-Time Embedded Systems
SWE 760 Lecture 1: Introduction to Analysis & Design of Real-Time Embedded Systems Hassan Gomaa References: H. Gomaa, Chapters 1, 2, 3 - Real-Time Software Design for Embedded Systems, Cambridge University
More informationCase Study KAPE Smart Beef Traceability System Enhancement
Case Study KAPE Smart Beef Traceability System Enhancement KAPE The Korea Institute for Animal Products Quality Evaluation (KAPE) is a state-run organization established in 1989 to evaluate the quality
More informationSoftware Engineering Chap.7 - Design and Implementation
Software Engineering Chap.7 - Design and Implementation Simão Melo de Sousa RELEASE (UBI), LIACC (Porto), CCTC (Minho) Computer Science Department University of Beira Interior, Portugal Eng.Info./TSI,
More informationProgress Report. Object-Oriented Software Development: Requirements elicitation (ch. 4) and analysis (ch. 5) Object-oriented software development
Progress Report Object-Oriented Software Development: Requirements elicitation (ch. 4) and analysis (ch. 5) CS 4354 Summer II 2014 Jill Seaman So far we have learned about the tools used in object-oriented
More informationSlides copyright 1996, 2001, 2005, 2009, 2014 by Roger S. Pressman. For non-profit educational use only
Chapter 16 Pattern-Based Design Slide Set to accompany Software Engineering: A Practitioner s Approach, 8/e by Roger S. Pressman and Bruce R. Maxim Slides copyright 1996, 2001, 2005, 2009, 2014 by Roger
More informationFundamentals to Creating Architectures using ISO/IEC/IEEE Standards
Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards What to Architect? How to Architect? IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define
More informationOBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis
UNIT I INTRODUCTION OBJECT ORIENTED SYSTEM DEVELOPMENT Software Development Dynamic System Development Information system solution Steps in System Development Analysis Design Implementation Testing Maintenance
More informationContent(2) Contribution of OOT in Software Engineering History of SE Technologies and Contribution of OOT JAIST Koichiro Ochimizu
Content(2) Object-oriented Software Development Methodology Outline of Unified Process and Use-case Driven Approach Elevator Control System: Problem Description and Use-case Model Elevator Control System:
More informationThe Design Patterns Matrix From Analysis to Implementation
The Design Patterns Matrix From Analysis to Implementation This is an excerpt from Shalloway, Alan and James R. Trott. Design Patterns Explained: A New Perspective for Object-Oriented Design. Addison-Wesley
More informationConcurrent Object-Oriented Development with Behavioral Design Patterns
Concurrent Object-Oriented Development with Behavioral Design Patterns Benjamin Morandi 1, Scott West 1, Sebastian Nanz 1, and Hassan Gomaa 2 1 ETH Zurich, Switzerland 2 George Mason University, USA firstname.lastname@inf.ethz.ch
More informationOBJECT-ORIENTED MODELING AND DESIGN. Process Overview
OBJECT-ORIENTED MODELING AND DESIGN Process Overview CONTENTS: 1. Development Stages. 2. Development Life Cycle. 3. Summary. A software Development process provides a basis for the organized production
More informationObject-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur
Object-Oriented Analysis and Design Prof. Partha Pratim Das Department of Computer Science and Engineering Indian Institute of Technology-Kharagpur Lecture 06 Object-Oriented Analysis and Design Welcome
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 informationHUMIT Interactive Data Integration in a Data Lake System for the Life Sciences
HUMIT Interactive Data Integration in a Data Lake System for the Life Sciences PD Dr. Christoph Quix Fraunhofer-Institut für Angewandte Informationstechnik FIT Life Science Informatics Abteilungsleiter
More informationObject Orientated Analysis and Design. Benjamin Kenwright
Notation Part 2 Object Orientated Analysis and Design Benjamin Kenwright Outline Review What do we mean by Notation and UML? Types of UML View Continue UML Diagram Types Conclusion and Discussion Summary
More informationHPE Enterprise Maps Data Model, ArchiMate, TOGAF. HPE Software, Cloud and Automation
HPE Enterprise Maps Data Model, ArchiMate, TOGAF HPE Software, Cloud and Automation Data Model Enterprise Maps ArchiMate Overview Modeling language for EA 2002-2004 - NL university + government + industry
More informationSOFTWARE DESIGN COSC 4353 / Dr. Raj Singh
SOFTWARE DESIGN COSC 4353 / 6353 Dr. Raj Singh UML - History 2 The Unified Modeling Language (UML) is a general purpose modeling language designed to provide a standard way to visualize the design of a
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 7 Integrated Object-Oriented Methodologies: OPEN and FOOM 1 Object-oriented Process, Environment and Notation (OPEN) First introduced in
More informationTowards a formal model of object-oriented hyperslices
Towards a formal model of object-oriented hyperslices Torsten Nelson, Donald Cowan, Paulo Alencar Computer Systems Group, University of Waterloo {torsten,dcowan,alencar}@csg.uwaterloo.ca Abstract This
More informationComponent-Based Software Engineering TIP
Component-Based Software Engineering TIP X LIU, School of Computing, Napier University This chapter will present a complete picture of how to develop software systems with components and system integration.
More informationITSS Model Curriculum. - To get level 3 -
ITSS Model Curriculum - To get level 3 - (Corresponding with ITSS V3) IT Skill Standards Center IT Human Resources Development Headquarters Information-Technology Promotion Agency (IPA), JAPAN Company
More informationOverview of Sentence Order Reference Document Development Process
Overview of Sentence Order Reference Document Development Process Scott Came Justice Integration Solutions, Inc. September 14, 2004 Purpose The purpose of this document is to outline the process/methodology
More informationPurpose. ERO Enterprise-Endorsed Implementation Guidance
Lesson Learned CIP Version 5 Transition Program CIP-002-5.1 Requirement R1: Impact Rating of Generation Resource Shared BES Cyber Systems Version: January 29, 2015 Authorized by the Standards Committee
More informationUsability Evaluation as a Component of the OPEN Development Framework
Usability Evaluation as a Component of the OPEN Development Framework John Eklund Access Testing Centre and The University of Sydney 112 Alexander Street, Crows Nest NSW 2065 Australia johne@testingcentre.com
More informationExamples. Object Orientated Analysis and Design. Benjamin Kenwright
Examples Object Orientated Analysis and Design Benjamin Kenwright Outline Revision Questions Group Project Review Deliverables Example System Problem Case Studey Group Project Case-Study Example Vision
More informationDimensions for the Separation of Concerns in Describing Software Development Processes
Dimensions for the Separation of Concerns in Describing Software Development Processes Pavel Hruby Navision Software Frydenlunds Allé 6 DK-2950 Vedbæk, Denmark ph@navision.com http://www.navision.com,
More informationArchitectural Modeling in SysML
Architectural Modeling in SysML A Practical Approach to Mapping Functions to Logical Architectural Variants Michael J. Vinarcik, ESEP-Acq, OCSMP-Model Builder Advanced Booz Allen Hamilton National Defense
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 informationCompositional Model Based Software Development
Compositional Model Based Software Development Prof. Dr. Bernhard Rumpe http://www.se-rwth.de/ Seite 2 Our Working Groups and Topics Automotive / Robotics Autonomous driving Functional architecture Variability
More informationSoftware Engineering
Software Engineering chap 4. Software Reuse 1 SuJin Choi, PhD. Sogang University Email: sujinchoi@sogang.ac.kr Slides modified, based on original slides by Ian Sommerville (Software Engineering 10 th Edition)
More informationA Capacity Planning Methodology for Distributed E-Commerce Applications
A Capacity Planning Methodology for Distributed E-Commerce Applications I. Introduction Most of today s e-commerce environments are based on distributed, multi-tiered, component-based architectures. The
More informationto schedule pressure
Last week WinWord 1.0 Business proposal Project Estimation: size, effort, schedule size: LOC, FP effort: man-months Microsoft Word for Windows 1.0 Example of overly optimistic schedule 5 years in development,
More informationDeveloping Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach
Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Ninat Wanapan and Somnuk Keretho Department of Computer Engineering, Kasetsart
More informationefmea RAISING EFFICIENCY OF FMEA BY MATRIX-BASED FUNCTION AND FAILURE NETWORKS
efmea RAISING EFFICIENCY OF FMEA BY MATRIX-BASED FUNCTION AND FAILURE NETWORKS Maik Maurer Technische Universität München, Product Development, Boltzmannstr. 15, 85748 Garching, Germany. Email: maik.maurer@pe.mw.tum.de
More informationSmart Commissioning. White Paper January 2019
is a technology-enabled approach for streamlining the commissioning of field instrumentation connected to a DeltaV Distributed Control System (DCS) or Safety Instrumented System (SIS). It reduces the effort
More informationThe Mission of the Abu Dhabi Smart Solutions and Services Authority. Leading ADSSSA. By Michael J. Keegan
Perspective on Digital Transformation in Government with Her Excellency Dr. Rauda Al Saadi, Director General, Abu Dhabi Smart Solutions and Services Authority By Michael J. Keegan Today s digital economy
More informationHistory of object-oriented approaches
Prof. Dr. Nizamettin AYDIN naydin@yildiz.edu.tr http://www.yildiz.edu.tr/~naydin Object-Oriented Oriented Systems Analysis and Design with the UML Objectives: Understand the basic characteristics of object-oriented
More informationREVIEW AND OUTLOOKS OF THE MEANS FOR VISUALIZATION OF SYNTAX SEMANTICS AND SOURCE CODE. PROCEDURAL AND OBJECT ORIENTED PARADIGM DIFFERENCES
REVIEW AND OUTLOOKS OF THE MEANS FOR VISUALIZATION OF SYNTAX SEMANTICS AND SOURCE CODE. PROCEDURAL AND OBJECT ORIENTED PARADIGM DIFFERENCES Hristo Hristov Abstract. In the article, we have reviewed the
More informationDeriving design aspects from canonical models
Deriving design aspects from canonical models Bedir Tekinerdogan & Mehmet Aksit University of Twente Department of Computer Science P.O. Box 217 7500 AE Enschede, The Netherlands e-mail: {bedir aksit}@cs.utwente.nl
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 informationSoftware Life Cycle. Main issues: Discussion of different life cycle models Maintenance or evolution
Software Life Cycle Main issues: Discussion of different life cycle models Maintenance or evolution Introduction software development projects are large and complex a phased approach to control it is necessary
More informationUNIT-I Introduction of Object Oriented Modeling
UNIT-I Introduction of Object Oriented Modeling - Prasad Mahale Object Oriented Modeling and Reference Books: Design 1. Grady Booch, James Rumbaugh, Ivar Jacobson Unified Modeling Language User Guide,
More informationPattern-Oriented Development with Rational Rose
Pattern-Oriented Development with Rational Rose Professor Peter Forbrig, Department of Computer Science, University of Rostock, Germany; Dr. Ralf Laemmel, Department of Information Management and Software
More informationPERSPECTIVE. End-to-end test automation A behaviordriven and tool-agnostic approach. Abstract
PERSPECTIVE End-to-end test automation A behaviordriven and tool-agnostic approach Anand Avinash Tambey Product Technical Architect, Infosys Abstract In today s fast changing world, IT is under constant
More informationAccelerates Timelines for Development and Deployment of Coatings for Consumer Products.
May 2010 PPG Color Launch Process Accelerates Timelines for Development and Deployment of Coatings for Consumer Products. Inspire Market Feedback/Sales Design Color Develop Designer Mass Production Marketing
More informationehealth Ministerial Conference 2013 Dublin May 2013 Irish Presidency Declaration
ehealth Ministerial Conference 2013 Dublin 13 15 May 2013 Irish Presidency Declaration Irish Presidency Declaration Ministers of Health of the Member States of the European Union and delegates met on 13
More information