DOCSLIB.ORG

Object-Oriented Software Development Methodologies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Object-Oriented Software Development Methodologies Process-centred Review of Object Oriented Software Development Methodologies Technical Report Raman Ramsin and Richard F. Paige Department of Computer Science The University of York Heslington York YO10 5DD United Kingdom {ramsin, paige}@cs.york.ac.uk June 2004 Abstract The applicability of the object-oriented approach to systems analysis and design has long been recognized, and as a result, the software industry has witnessed the advent of a plethora of object-oriented software development methodologies. These methodologies have been widely acclaimed as promising means for tackling the software crisis, yet their sheer number and diversity has become detrimental to their widespread adoption into the software engineering community. Efforts aimed at unification and standardization have been mostly focused on modeling languages, and methodologists have had limited success in integrating methodologies. Scant as they have been, attempts at integration, unification and standardization have actually aggravated the problems of complexity and inconsistency, giving rise to a new family of lightweight methodologies that eccentrically defy the long-established values of modeling and process-based development. These and other issues have necessitated further research in the field, with the ultimate purpose of developing practical and adoptable object-oriented methodologies. This report reviews existing methodologies as a prelude to a project aimed at developing a methodology addressing the problem issues. The review aims at abstracting away the less important features of the methodologies and laying bare their core philosophy and process. This is done by using a process-centred template for summarizing the methodologies, highlighting the activities prescribed in the methodology while describing the modeling notations used (mainly diagrams and tables) as secondary to the activities. The descriptions produced using this template offer little critique on the methodologies, yet abstract and structure them in a way that facilitates their elaborate analysis. Keywords: Software Development Methodology, Object-oriented Development, Modeling Language, Process. Table of Contents 1 INTRODUCTION .................................................................................................................................................... 1 1.1 MOTIVATION ....................................................................................................................................................... 1 1.2 PROJECT OBJECTIVES AND APPROACH ................................................................................................................. 2 1.3 AIM OF THE REPORT............................................................................................................................................. 3 1.4 STRUCTURE OF THE REPORT ................................................................................................................................3 2 SOFTWARE DEVELOPMENT METHODOLOGY: MODELING LANGUAGE + PROCESS .................... 5 3 OBJECT-ORIENTED METHODOLOGIES: A BRIEF HISTORY................................................................... 5 4 SEMINAL METHODOLOGIES: FIRST AND SECOND GENERATIONS..................................................... 7 4.1 SHLAER-MELLOR (1988, 1992)........................................................................................................................... 8 4.1.1 Partitioning the system into domains (Shlaer-Mellor)................................................................................ 8 4.1.2 Analyzing the application domain (Shlaer-Mellor) .................................................................................... 9 4.1.3 Confirming the analysis (Shlaer-Mellor).................................................................................................. 10 4.1.4 Extracting the requirements for the service domains (Shlaer-Mellor) ..................................................... 10 4.1.5 Analyzing the service domains (Shlaer-Mellor): ...................................................................................... 10 4.1.6 Specifying the components of the architectural domain (Shlaer-Mellor) ................................................. 11 4.1.7 Building the architectural components (Shlaer-Mellor)...........................................................................11 4.1.8 Translating the models of each domain (Shlaer-Mellor)..........................................................................11 4.2 COAD-YOURDON (1989, 1991).......................................................................................................................... 13 4.2.1 Analysis (Coad-Yourdon).......................................................................................................................... 13 4.2.2 Design (Coad-Yourdon)............................................................................................................................ 14 4.3 RDD (1990) ...................................................................................................................................................... 16 4.3.1 Exploratory Phase (RDD)......................................................................................................................... 16 4.3.2 Analysis Phase (RDD) .............................................................................................................................. 17 4.4 BOOCH (1991, 1994) ......................................................................................................................................... 19 4.4.1 Macro Process (Booch) ............................................................................................................................ 19 4.4.2 Micro Process (Booch) ............................................................................................................................. 20 4.5 OMT (1991)...................................................................................................................................................... 26 4.5.1 Analysis (OMT)......................................................................................................................................... 27 4.5.2 System Design (OMT)............................................................................................................................... 28 4.5.3 Object Design (OMT) ............................................................................................................................... 29 4.6 OSA (1992)....................................................................................................................................................... 30 4.6.1 Object-Relationship Model – ORM (OSA)................................................................................................ 31 4.6.2 Object-Behaviour Model – OBM (OSA) ................................................................................................... 31 4.6.3 Object-Interaction Model - OIM (OSA)................................................................................................... 32 4.6.4 High-level views (OSA)............................................................................................................................. 32 4.7 OOSE (1992) .................................................................................................................................................... 34 4.7.1 Analysis (OOSE)....................................................................................................................................... 34 4.7.1.1 Requirements Analysis ......................................................................................................................... 34 4.7.1.2 Robustness Analysis ............................................................................................................................. 37 4.7.2 Construction (OOSE)................................................................................................................................ 37 4.7.2.1 Design................................................................................................................................................... 38 4.7.2.2 Implementation ..................................................................................................................................... 39 4.7.3 Testing (OOSE)......................................................................................................................................... 40 4.8 BON (1992, 1995) ............................................................................................................................................ 41 4.8.1 Delineating System Borderline (BON)...................................................................................................... 43 4.8.2 Listing Candidate Classes (BON)............................................................................................................. 45 4.8.3 Selecting Classes and Grouping into Clusters (BON) ..............................................................................45 4.8.4 Defining Classes (BON)............................................................................................................................ 47 4.8.5 Sketching System Behaviour (BON).......................................................................................................... 47 4.8.6 Defining
Load more

Recommended publications
  • Plantuml Language Reference Guide (Version 1.2021.2)
    Drawing UML with PlantUML PlantUML Language Reference Guide (Version 1.2021.2) PlantUML is a component that allows to quickly write : • Sequence diagram • Usecase diagram • Class diagram • Object diagram • Activity diagram • Component diagram • Deployment diagram • State diagram • Timing diagram The following non-UML diagrams are also supported: • JSON Data • YAML Data • Network diagram (nwdiag) • Wireframe graphical interface • Archimate diagram • Specification and Description Language (SDL) • Ditaa diagram • Gantt diagram • MindMap diagram • Work Breakdown Structure diagram • Mathematic with AsciiMath or JLaTeXMath notation • Entity Relationship diagram Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence -> is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. Note that this is only true for sequence diagrams, rules are different for the other diagrams. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: Another authentication Response @enduml 1.2 Declaring participant If the keyword participant is used to declare a participant, more control on that participant is possible. The order of declaration will be the (default) order of display. Using these other keywords to declare participants
    [Show full text]
  • Real Time UML
    Fr 5 January 22th-26th, 2007, Munich/Germany Real Time UML Bruce Powel Douglass Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com RealReal--TimeTime UMLUML Bruce Powel Douglass, PhD Chief Evangelist Telelogic Systems and Software Modeling Division www.telelogic.com/modeling groups.yahoo.com/group/RT-UML 1 Real-Time UML © Telelogic AB Basics of UML • What is UML? – How do we capture requirements using UML? – How do we describe structure using UML? – How do we model communication using UML? – How do we describe behavior using UML? • The “Real-Time UML” Profile • The Harmony Process 2 Real-Time UML © Telelogic AB What is UML? 3 Real-Time UML © Telelogic AB What is UML? • Unified Modeling Language • Comprehensive full life-cycle 3rd Generation modeling language – Standardized in 1997 by the OMG – Created by a consortium of 12 companies from various domains – Telelogic/I-Logix a key contributor to the UML including the definition of behavioral modeling • Incorporates state of the art Software and Systems A&D concepts • Matches the growing complexity of real-time systems – Large scale systems, Networking, Web enabling, Data management • Extensible and configurable • Unprecedented inter-disciplinary market penetration – Used for both software and systems engineering • UML 2.0 is latest version (2.1 in process…) 4 Real-Time UML © Telelogic AB UML supports Key Technologies for Development Iterative Development Real-Time Frameworks Visual Modeling Automated Requirements-
    [Show full text]
  • Fakulta Informatiky UML Modeling Tools for Blind People Bakalářská
    Masarykova univerzita Fakulta informatiky UML modeling tools for blind people Bakalářská práce Lukáš Tyrychtr 2017 MASARYKOVA UNIVERZITA Fakulta informatiky ZADÁNÍ BAKALÁŘSKÉ PRÁCE Student: Lukáš Tyrychtr Program: Aplikovaná informatika Obor: Aplikovaná informatika Specializace: Bez specializace Garant oboru: prof. RNDr. Jiří Barnat, Ph.D. Vedoucí práce: Mgr. Dalibor Toth Katedra: Katedra počítačových systémů a komunikací Název práce: Nástroje pro UML modelování pro nevidomé Název práce anglicky: UML modeling tools for blind people Zadání: The thesis will focus on software engineering modeling tools for blind people, mainly at com•monly used models -UML and ERD (Plant UML, bachelor thesis of Bc. Mikulášek -Models of Structured Analysis for Blind Persons -2009). Student will evaluate identified tools and he will also try to contact another similar centers which cooperate in this domain (e.g. Karlsruhe Institute of Technology, Tsukuba University of Technology). The thesis will also contain Plant UML tool outputs evaluation in three categories -students of Software engineering at Faculty of Informatics, MU, Brno; lecturers of the same course; person without UML knowledge (e.g. customer) The thesis will contain short summary (2 standardized pages) of results in English (in case it will not be written in English). Literatura: ARLOW, Jim a Ila NEUSTADT. UML a unifikovaný proces vývoje aplikací : průvodce ana­lýzou a návrhem objektově orientovaného softwaru. Brno: Computer Press, 2003. xiii, 387. ISBN 807226947X. FOWLER, Martin a Kendall SCOTT. UML distilled : a brief guide to the standard object mode•ling language. 2nd ed. Boston: Addison-Wesley, 2000. xix, 186 s. ISBN 0-201-65783-X. Zadání bylo schváleno prostřednictvím IS MU. Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně.
    [Show full text]
  • Com.Telelogic.Rhapsody.Core
    com.telelogic.rhapsody.core Package Class Use Tree Serialized Deprecated Index Help PREV PACKAGE NEXT PACKAGE FRAMES NO FRAMES All Classes Package com.telelogic.rhapsody.core Interface Summary The IRPAcceptEventAction interface represents Accept Event IRPAcceptEventAction Action elements in a statechart or activity diagram. The IRPAcceptTimeEvent interface represents Accept Time Event IRPAcceptTimeEvent elements in activity diagrams and statecharts. The IRPAction interface represents the action defined for a IRPAction transition in a statechart. The IRPActionBlock interface represents action blocks in IRPActionBlock sequence diagrams. The IRPActivityDiagram interface represents activity diagrams in IRPActivityDiagram Rational Rhapsody models. IRPActor The IRPActor interface represents actors in Rhapsody models. The IRPAnnotation interface represents the different types of IRPAnnotation annotations you can add to your model - notes, comments, constraints, and requirements. The IRPApplication interface represents the Rhapsody application, IRPApplication and its methods reflect many of the commands that you can access from the Rhapsody menu bar. The IRPArgument interface represents an argument of an IRPArgument operation or an event. IRPASCIIFile The IRPAssociationClass interface represents association classes IRPAssociationClass in Rational Rhapsody models. The IRPAssociationRole interface represents the association roles IRPAssociationRole that link objects in communication diagrams. The IRPAttribute interface represents attributes of
    [Show full text]
  • Efficient Generation of Graphical Model Views Via Lazy Model-To-Text Transformation
    This is a repository copy of Efficient Generation of Graphical Model Views via Lazy Model- to-Text Transformation. White Rose Research Online URL for this paper: https://eprints.whiterose.ac.uk/164209/ Version: Accepted Version Proceedings Paper: Kolovos, Dimitris orcid.org/0000-0002-1724-6563, De La Vega, Alfonso and Cooper, Justin (Accepted: 2020) Efficient Generation of Graphical Model Views via Lazy Model-to-Text Transformation. In: ACM/IEEE 23rd International Conference on Model Driven Engineering Languages and Systems (MODELS ’20). (In Press) Reuse Items deposited in White Rose Research Online are protected by copyright, with all rights reserved unless indicated otherwise. They may be downloaded and/or printed for private study, or other acts as permitted by national copyright laws. The publisher or other rights holders may allow further reproduction and re-use of the full text version. This is indicated by the licence information on the White Rose Research Online record for the item. Takedown If you consider content in White Rose Research Online to be in breach of UK law, please notify us by emailing [email protected] including the URL of the record and the reason for the withdrawal request. [email protected] https://eprints.whiterose.ac.uk/ Efficient Generation of Graphical Model Views via Lazy Model-to-Text Transformation Dimitris Kolovos Alfonso de la Vega Justin Cooper Department of Computer Science Department of Computer Science Department of Computer Science University of York University of York University of York York, UK York, UK York, UK [email protected] [email protected] [email protected] ABSTRACT transforming them into textual formats such as Graphviz, Plan- Producing graphical views from software and system models is tUML, SVG and HTML, which are subsequently rendered in an often desirable for communication and comprehension purposes, embedded browser.
    [Show full text]
  • Campinas 2019 Universidade Estadual De Campinas
    UNIVERSIDADE ESTADUAL DE CAMPINAS Faculdade de Engenharia Elétrica e de Computação RAMON CRAVO FERNANDES ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA CAMPINAS 2019 RAMON CRAVO FERNANDES ARES: UM PROCESSO CENTRADO EM MODELAGEM PARA PESQUISA APLICADA EM ENGENHARIA Dissertação de Mestrado apresentada à Faculdade de Engenharia Elétrica e de Computação da Universidade Estadual de Campinas para obtenção do título de Mestre em Engenharia Elétrica, na área de Engenharia Biomédica. Orientador: Prof. Dr. Eduardo Tavares Costa ESTE TRABALHO CORRESPONDE À VERSÃO FINAL DA DISSERTAÇÃO DEFENDIDA PELO ALUNO RAMON CRAVO FERNANDES, E ORIENTADA PELO PROF. DR. EDUARDO TAVARES COSTA CAMPINAS 2019 COMISSÃO JULGADORA – DISSERTAÇÃO DE MESTRADO Candidato: Ramon Cravo Fernandes RA: 142386 Data da Defesa: 20 de fevereiro de 2019 Título da Tese: “ARES: Um processo centrado em modelagem para pesquisa aplicada em engenharia” Prof. Dr. Eduardo Tavares Costa (Presidente) Prof. Dr. Eduardo Jorge Valadares Oliveira Prof. Dr. José Wilson Magalhães Bassani A ata de defesa, com as respectivas assinaturas dos membros da Comissão Juldadora, encontra-se no SIGA (Sistema de Fluxo de Dissertação/Tese) e na Secretaria de Pós-Graduação da Faculdade de Engenharia Elétrica e de Computação RESUMO A inovação enquanto sistema constrói-se sobre as relações entre seus agentes, materializada pelas trocas e transferências de conhecimento e tecnologias. Neste contexto, a pesquisa torna-se parte do sistema de inovação, e a produção de conhecimento um empreendimento de facto. Assim, o empreendedorismo acadêmico é um processo de internalização das atividades de transferência tecnológica e de conhecimento. Na tentativa de abordar as questões referentes à gestão de interfaces entre os produtores de conhecimento e tecnologia (universidades, organizações e centros de pesquisa e desenvolvimento, etc.) e os demais atores da inovação, suas interdependências e iteratividades, esta dissertação apresenta o desenvolvimento de um processo centrado em modelagem e simulação, denominado processo ARES.
    [Show full text]
  • The Flexible Multi-Level Modelling and Execution Language (Fmmlx). Version 2.0: Analysis of Requirements and Technical Terminology
    A Service of Leibniz-Informationszentrum econstor Wirtschaft Leibniz Information Centre Make Your Publications Visible. zbw for Economics Frank, Ulrich Research Report The Flexible Multi-Level Modelling and Execution Language (FMMLx). Version 2.0: Analysis of requirements and technical terminology ICB-Research Report, No. 66 Provided in Cooperation with: University Duisburg-Essen, Institute for Computer Science and Business Information Systems (ICB) Suggested Citation: Frank, Ulrich (2018) : The Flexible Multi-Level Modelling and Execution Language (FMMLx). Version 2.0: Analysis of requirements and technical terminology, ICB-Research Report, No. 66, Universität Duisburg-Essen, Institut für Informatik und Wirtschaftsinformatik (ICB), Essen, http://dx.doi.org/10.17185/duepublico/47506 This Version is available at: http://hdl.handle.net/10419/194002 Standard-Nutzungsbedingungen: Terms of use: Die Dokumente auf EconStor dürfen zu eigenen wissenschaftlichen Documents in EconStor may be saved and copied for your Zwecken und zum Privatgebrauch gespeichert und kopiert werden. personal and scholarly purposes. Sie dürfen die Dokumente nicht für öffentliche oder kommerzielle You are not to copy documents for public or commercial Zwecke vervielfältigen, öffentlich ausstellen, öffentlich zugänglich purposes, to exhibit the documents publicly, to make them machen, vertreiben oder anderweitig nutzen. publicly available on the internet, or to distribute or otherwise use the documents in public. Sofern die Verfasser die Dokumente unter Open-Content-Lizenzen (insbesondere CC-Lizenzen) zur Verfügung gestellt haben sollten, If the documents have been made available under an Open gelten abweichend von diesen Nutzungsbedingungen die in der dort Content Licence (especially Creative Commons Licences), you genannten Lizenz gewährten Nutzungsrechte. may exercise further usage rights as specified in the indicated licence.
    [Show full text]
  • Experience from Introducing Unified Modeling Language/Systems Modeling Language at Saab Aerosystems
    Regular Paper Experience from Introducing Unified Modeling Language/Systems Modeling Language at Saab Aerosystems Henric Andersson,1, * Erik Herzog,1 Gert Johansson,2 and Olof Johansson3 1Saab Aerosystems AB, Brödern Ugglas gata, SE-581 88 Linköping, Sweden 2Combitech AB, SE-580 15 Linköping, Sweden 3Linköping University, Linköping, Sweden INTRODUCING UML/SysML AT SAAB AEROSYSTEMS Received 17 September 2008; Revised 23 February 2009; Accepted 31 August 2009, after one or more revisions Published online 9 November 2009 in Wiley Online Library (wileyonlinelibrary.com) DOI 10.1002/sys.20156 ABSTRACT A Unified Modeling Language/Systems Modeling Language (UML/SysML) subset was the modeling notation selected for an aerospace systems engineering project at Saab Aerosystems. In this paper, the rationale for selecting UML/SysML is given, along with a description of the situation at the project planning stage regarding business conditions, method and tools support. The usage of use case, sequence, and activity diagrams are described as well as definition of functional chains with SysML. Furthermore, the connections to system implementation activities including code generation and simulation are discussed. The advantages and disadvantages of using UML/SysML from experience in an industrial context are reported. It is also described how UML/SysML is related to industrial research projects in the Model Based Systems Engineering (MBSE) methods and tools area. Introducing UML/SysML with a methodology and a supporting toolset in an operative organization require a clear strategy, including planning, just-in-time training, and mentor support. Finally, industrial needs for further development of SysML are discussed. © 2009 Wiley Periodicals, Inc. Syst Eng 13: 369–380, 2010 Key words: Systems Modeling Language; Unified Modeling Language; model based systems engineering; unmanned aerial vehicle 1.
    [Show full text]
  • Plantuml Language Reference Guide (Version 8023) 1 of 120 1.4 Use Non-Letters in Participants 1 SEQUENCE DIAGRAM
    Drawing UML with PlantUML Language Reference Guide (Version 8023) PlantUML is an Open Source project that allows to quickly write: • Sequence diagram, • Usecase diagram, • Class diagram, • Activity diagram, • Component diagram, • State diagram, • Object diagram. Diagrams are defined using a simple and intuitive language. 1 SEQUENCE DIAGRAM 1 Sequence Diagram 1.1 Basic examples The sequence "->" is used to draw a message between two participants. Participants do not have to be explicitly declared. To have a dotted arrow, you use --> It is also possible to use <- and <--. That does not change the drawing, but may improve readability. @startuml Alice -> Bob: Authentication Request Bob --> Alice: Authentication Response Alice -> Bob: Another authentication Request Alice <-- Bob: another authentication Response @enduml 1.2 Comments Everything that starts with simple quote ' is a comment. You can also put comments on several lines using /' to start and '/ to end. 1.3 Declaring participant It is possible to change participant order using the participant keyword. It is also possible to use other keywords to declare a participant: • actor • boundary • control • entity • database @startuml actor Foo1 boundary Foo2 control Foo3 entity Foo4 database Foo5 Foo1 -> Foo2 : To boundary Foo1 -> Foo3 : To control Foo1 -> Foo4 : To entity Foo1 -> Foo5 : To database @enduml PlantUML Language Reference Guide (Version 8023) 1 of 120 1.4 Use non-letters in participants 1 SEQUENCE DIAGRAM You can rename a participant using the as keyword. You can also change the background color of actor or participant. @startuml actor Bob #red ' The only difference between actor 'and participant is the drawing participant Alice participant "I have a really\nlong name" as L #99FF99 /' You can also declare: participant L as "I have a really\nlong name" #99FF99 '/ Alice->Bob: Authentication Request Bob->Alice: Authentication Response Bob->L: Log transaction @enduml 1.4 Use non-letters in participants You can use quotes to define participants.
    [Show full text]
  • Introduction to UML: Structural and Use Case Modeling
    Object Modeling with OMG UML Tutorial Series Introduction to UML: Structural and Use Case Modeling Cris Kobryn Co-Chair UML Revision Task Force [email protected] © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys Overview ! Tutorial series ! Quick tour ! Structural modeling ! Use case modeling Introduction to UML 2 Tutorial Series ! Lecture 1: Introduction to UML: Structural and Use Case Modeling ! Lecture 2: Behavioral Modeling with UML ! Lecture 3: Advanced Modeling with UML [Note: This version of the tutorial series is based on OMG UML Specification v. 1.4, OMG doc# ad/01-02-13, adopted in May 2001.] Introduction to UML 3 Tutorial Goals ! What you will learn: ! what the UML is and what is it not ! UML’s basic constructs, rules and diagram techniques ! how the UML can model large, complex systems ! how the UML can specify systems in an implementation-independent manner ! What you will not learn: ! object methods or processes ! metamodeling techniques Introduction to UML 4 Quick Tour ! Why do we model? ! What is the UML? ! Foundation elements ! Unifying concepts ! Language architecture ! Relation to other OMG technologies Introduction to UML 5 Why do we model? ! Provide structure for problem solving ! Experiment to explore multiple solutions ! Furnish abstractions to manage complexity ! Reduce time-to-market for business problem solutions ! Decrease development costs ! Manage the risk of mistakes Introduction to UML 6 The Challenge Tijuana “shantytown”: http://www.macalester.edu/~jschatz/residential.html Introduction to UML 7 The Vision Fallingwater: http://www.adelaide.net.au/~jpolias/FLW/Images/FallingWater.jpeg Introduction to UML 8 Why do we model graphically? ! Graphics reveal data.
    [Show full text]
  • Implementation of MBSE Approach for Developing Reliability Model to Ensure Robustness of Sounding Rocket Program Using Made Modeling Tool
    Proceedings of the 9th Annual World Conference of the Society for Industrial and Systems Engineering, 2020 SISE Virtual Conference September 17-18, 2020 Implementation of MBSE Approach for Developing Reliability Model to Ensure Robustness of Sounding Rocket Program Using MADe Modeling Tool T Odita, MJ Louise-Caballes, and G Chen Morgan State University Baltimore, MD, USA Corresponding author’s Email: [email protected] Abstract: NASA Sounding Rocket Program (NSRP) is a research-based program that heavily targets relevant institutions to conduct studies for atmospheric research in space. The program has been operating for over 40 years. NASA's goal is to use Sounding Rockets to allow colleges and universities to carry out scientific research missions, particularly low gravity, and material-based research. Due to the Sounding Rocket's complexity, the implementation of a Model-Based Systems Engineering (MBSE) approach was utilized in both functionality and capability to generate a model-based systems diagram and provide a robust design for reliability, risk, and safety. Through the MADe tool usage, both Failure-Modes-Effects and Critical Analysis (FMECA) and Fault Tree Analysis (FTA) was designed and evaluated. The specifications of the rocket's fuel flow and engine were used as the basis of the study and how it affects the Systems Development Life Cycle (SDLC) of the Sounding Rocket. Whereas, the generated model-based system diagram can be used for risk assessment, to identify the possibility of failures and causes and critical errors that may affect the reliability of the Sounding Rocket. Through the MBSE approach, this research can bridge the current gap by utilizing MADe as the primary modeling tool to develop and design a model-based systems diagram to meet the current needs of Reliability Engineering within NSRP and Safety and Mission Assurance (SMA).
    [Show full text]
  • Security SPI Implementation Table of Contents
    Security SPI Implementation Table of Contents Domain Model. 3 Screenshots . 4 Automatically Seeds Roles . 4 Add permission at different scopes . 6 Permissions can ALLOW or VETO access . 6 Permissions can apply to VIEWING or CHANGING the feature . 7 Specify package . 8 Application users . 8 User Sign-up (Self-Registration) . 9 Application Tenancy . 13 How to configure/use . 16 Classpath . 16 Shiro configuration (shiro.ini) . 16 Bootstrapping . 17 Configuration Properties . 18 Overriding the schema. 20 API and Implementation . 21 PasswordEncryptionService . 21 PermissionsEvaluationService . 21 Default Roles, Permissions and Users . 22 Known issues . 23 Dependencies . 24 This module (isis-module-security) provides the ability to manage users, roles, and permissions. Users have roles, roles have permissions, and permissions are associated with application features. These features are derived from the Isis metamodel and can be scoped at either a package, class or individual class member. Permissions themselves can either allow or veto the ability to view or change any application feature. A key design objective of this module has been to limit the amount of permissioning data required. To support this objective: • permissions are hierarchical: a class-level permission applies to all class members, while a package-level permission applies to all classes of all subpackages • permissions can allow or veto access; thus a role can be granted access to most features, but excluded from selective others • permissions are scoped: a member-level permission overrides a class-level permission, a class-level permission overrides a package-level permission; the lower-level package permission overrides a higher-level one (eg com.mycompany.invoicing overrides com.mycompany).
    [Show full text]