DOCSLIB.ORG

Lecture 5: 10.02.2014 Arne-Jørgen Berre

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Lecture 5: 10.02.2014 Arne-Jørgen Berre INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 5: 10.02.2014 Arne-Jørgen Berre [email protected] or [email protected] Telecom and Informatics 1 Oblig 1 – Group work – Service Innovation and Design “TravelAdvisor” 1. Business Model – Osterwalder/Strategyzer.com 2. Service Design – with smaply.com Personas, Stakeholder maps, Customer/Service journey maps 3. BPMN diagrams (use of Cameo EA MagicDraw) 4. User stories (Agile) and selected Use cases (use of Cameo EA MagicDraw) 5. UI Mockup (Balsamiq) 6. Non functional requirements Telecom and Informatics 2 Obligs Partially individual, partially group - in 3 parts Oblig 1 – Group “TravelAdvisor” - Business architecture service design and use cases/requirement models (March 10) Oblig 2 – Individual – Eclipse EMF editor with Graphiti for “Business Architecture DSL” (April 7) Oblig 3 – Group “TravelAdvisor” system architecture and realisation with WebRatio/IFML (May 5) Telecom and Informatics 3 INF5120 - Lecture plan - 2014 1 (13/1): Introduction – overview of the course. Enterprise Architecture with UML and BPMN and DSLs 2 (20/1): Business Architecture – Business Model Canvas and Business Model Innovation with Value Networks, Strategyzer tool. BPMN modeling, MagicDraw EA tool 3: (27/1): Service Innovation and Service Design, AT ONE, Smaply – BPMN Examples 4 (3/2): User experience and Touchpoints/UI Design – Balsamiq/WebRatio 5 (10/2): UML and Req.Modeling –Agile User stories versus Use cases 2.0 6 (17/2): Requirements Modeling, Goal Modeling, BMM, and Non Functional requirements – Requirements Engineering 7 (24/2): UI Models, WebML and IFML, Process models (WebRatio) 8 (3/3): Model driven engineering – Metamodels, DSL, UML Profiles 9 (10/3): Model driven engineering, transformation technologies 10(17/3): Method Engineering, SW Process frameworks , SPEM/EPF, ISO 24744, FACESEM/ESSENCE (Brian Elvesæter) 11(24/3): MDE and DSL in practice, with ThingML example 12(31/3): System Architecture and Information/Ontology modeling, UML, ISO 19103 13(7/4): UML Service Modeling – SoaML, UML 2.0 Service composition, MagicDraw EASTER 14(28/4): Platform models for the Cloud, with CloudML (Alessandro Rossini) 15(5/5): System realisation models (MagicDraw, JEE), MDA-ADM, SBVR, MDI 16(12/5): Conclusion and Summary for INF5120 - Final Oblig review 17(19/5): Preparation for Exam Exam: Monday June 2nd, 2014, (4 hours) Telecom and Informatics 4 INF5120 - Exercise plan - 2014 1 (13/1): Introduction 2 (20/1): Business Architecture 3: (27/1): Service Innovation and Service Design, AT ONE, Smaply – BPMN Examples 4 (3/2): Demo: Strategyzer, Smaply, Balsamiq 5 (10/2): Group presentation: Strategyzer – Business Model 6 (17/2): Group presentation: Smaply Service Design 7 (24/2): Group presentation: Use cases/user stories with BPMN 8 (3/3): Group presentation: UI Design, Balsamiq , Eclipse intro 9 (10/3): Delivery of Oblig 1 - Discussion 10(17/3): EMF metamodel presentation 11(24/3): Graphiti presentations 12(31/3): Graphiti presentation 13(7/4): Delivery of Oblig 2 – Discussion, and IFML EASTER 14(28/4): IFML 15(5/5): Delivery of Oblig 3 16(12/5): Conclusion and Summary for INF5120 - Final Oblig review 17(19/5): Preparation for Exam – Old exams Exam: Monday June 2nd, 2014, (4 hours) Telecom and Informatics 5 Strategyzer (Osterwalder) Telecom and Informatics 6 Content Essential Unified Process Essworks and Essence – Principles and practices Software Development Essentials Product Essentials User stories and Agile Requirements Engineering Use Case Essentials Telecom and Informatics 7 Essence – Kernel and Language for Software Engineering Methods The joint submission for the OMG FACESEM standard “A Foundation for the Agile Creation and Enactment of Software Engineering Methods” [email protected] www.semat.org 8 Book is available now – Safaribooksonline/Addison Wesley 9 Problem Statement • Why do so few software development teams really use traditionally engineered methods and processes? – Methods viewed as being too heavyweight and inflexible (i.e., “not agile”) – Not enough flexibility for the team to customize and tailor the process they use (i.e., “be agile”) – The underlying metaphor “The process is the program, the team is the machine” doesn’t work. • As a result, develop teams end up with – An ad hoc development approach, or – An approach overly influenced by the latest “hot” fad, or – A limited tailoring of some method dictated to them. • This limits the ability of a team to be effective and scalable while remaining flexible and agile. 22 June 2011 Scope • Goal: To support a development team in defining, refining and customizing themselves the process they are actually using. • Approach: A framework that allows for the rapid construction of software methods for the team’s own use. • Standard: A common foundation for various such frameworks. • Foundational Concepts – Method – A systematic way of doing things in a particular discipline (software engineering). A method is composed from practices. – Practice – A general, repeatable approach to doing something with a specific purpose in mind, providing a systematic and verifiable way of addressing a particular aspect of the work at hand. – Enactment – The carrying out of a method in the context of a specific project effort. A method is an enactable composite practice. – Kernel – A domain model (for software engineering), providing a common terminology of concepts and their relationships that may be used in the definition of practices. – Language – A modeling language for specifying practices based on the kernel and for composing methods from the practices. 22 June 2011 Introduction to Essence 12 The Kernel A stripped-down, lightweight set of definitions that captures the essence of effective, The Kernel is described scalable software using a small subset of the engineering in a practice Language. independent way. 13 Alphas: The Essential Things to Work With Customer Solution Endeavor 14 Alphas: Example Requirements Description What the software system must do to address the opportunity and satisfy the stakeholders. It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system. Associations scopes and constrains : Work 15 Activity Spaces: The Essential Things to Do Explore Understand Ensure Stakeholder Use the System Possibilities Stakeholder Needs Satisfaction Understand the Shape Implement the Test Deploy Operate Requirements the System System the System the System the System Prepare to do Coordinate Support the Team Track Progress Stop the Work the Work Activity 16 Activity Spaces: Examples Scrum Essentials Practice Activity Space Activity Activity Predecessor Relationship 17 Focus areas • Embodies the essence of software engineering in a kernel. • Works with methods in an agile way that are as close to practitioners’ practice as possible. • Applies the principle of “separate of concerns”, focusing on the things that matter the most. • Focuses on helping the least experienced developers over helping more experienced developers. • Reflects an understanding that the majority of the development community is interested in… – the use of methods, not their definition. – practice, not process or method engineering. – intuitive and concrete graphical syntax, not formal semantics. 18 Introduction to The Essentials Module 1 – Principles and Practices Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Introduction to The Essentials Module 2 – Software Development Essentials Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Manifesto for Agile Software Development • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan http://agilemanifesto.org/ 22 Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved User Story template • I <in the role of XX> needs functionality <zzz> to achieve the goal of <YYY> 23 Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Backlog metamodel Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Inf5120.modelbased.net 25 Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved 26 Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Use case modeling Telecom and Informatics 27 Create GUI Mockups Balsamiq: http://www.balsamiq.com Telecom and Informatics 28 SiSaS – SINTEF Software as a Service Methodology, sisas.modelbased.net Telecom and Informatics 29 SiSaS – Disciplines and Practices Telecom and Informatics 30 Template of a Use Case Description ………. Telecom and Informatics Telecom and Informatics User Story template I <in the role of XX> needs functionality <zzz> to achieve the goal of <YYY> Telecom and Informatics 33 Backlog metamodel Telecom and Informatics Telecom and Informatics Introduction to The Essentials Module 3 – Use-Case Essentials Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Introduction to The Essentials Module 3 – Use-Case Essentials Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Use-Case 2.0 Module 2 – Finding Actors and Use Cases Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved Use-Case 2.0 Module 7 - Adapting Your Use-Case Model - Using Include and Extend Copyright © 2006-2010 Ivar Jacobson International SA. All rights reserved.
Load more

Recommended publications
  • The Guide to Succeeding with Use Cases
    USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0? 4 First Principles 5 Principle 1: Keep it simple by telling stories 5 Principle 2: Understand the big picture 5 Principle 3: Focus on value 7 Principle 4: Build the system in slices 8 Principle 5: Deliver the system in increments 10 Principle 6: Adapt to meet the team’s needs 11 Use-Case 2.0 Content 13 Things to Work With 13 Work Products 18 Things to do 23 Using Use-Case 2.0 30 Use-Case 2.0: Applicable for all types of system 30 Use-Case 2.0: Handling all types of requirement 31 Use-Case 2.0: Applicable for all development approaches 31 Use-Case 2.0: Scaling to meet your needs – scaling in, scaling out and scaling up 39 Conclusion 40 Appendix 1: Work Products 41 Supporting Information 42 Test Case 44 Use-Case Model 46 Use-Case Narrative 47 Use-Case Realization 49 Glossary of Terms 51 Acknowledgements 52 General 52 People 52 Bibliography 53 About the Authors 54 USE-CASE 2.0 The Definitive Guide Page 2 © 2005-2011 IvAr JacobSon InternationAl SA. All rights reserved. About this Guide This guide describes how to apply use cases in an agile and scalable fashion. It builds on the current state of the art to present an evolution of the use-case technique that we call Use-Case 2.0.
    [Show full text]
  • UML Tutorial: Part 1 -- Class Diagrams
    UML Tutorial: Part 1 -- Class Diagrams. Robert C. Martin My next several columns will be a running tutorial of UML. The 1.0 version of UML was released on the 13th of January, 1997. The 1.1 release should be out before the end of the year. This col- umn will track the progress of UML and present the issues that the three amigos (Grady Booch, Jim Rumbaugh, and Ivar Jacobson) are dealing with. Introduction UML stands for Unified Modeling Language. It represents a unification of the concepts and nota- tions presented by the three amigos in their respective books1. The goal is for UML to become a common language for creating models of object oriented computer software. In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML. The Meta-model UML is unique in that it has a standard data representation. This representation is called the meta- model. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application. This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models. A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site2.
    [Show full text]
  • A Study on Process Description Method for DFM Using Ontology
    Invited Paper A Study on Process Description Method for DFM Using Ontology K. Hiekata1 and H. Yamato2 1Department of Systems Innovation, Graduate School of Engineering, The University of Tokyo, 5-1-5, Kashiwanoha, Kashiwa-city, Chiba 277-8563, Japan 2Department of Human and Engineered Environmental Studies, Graduate School of Frontier Sciences, The University of Tokyo, 5-1-5, Kashiwanoha, Kashiwa-city, Chiba 277-8563, Japan [email protected], [email protected] Abstract A method to describe process and knowledge based on RDF which is an ontology description language and IDEF0 which is a formal process description format is proposed. Once knowledge of experienced engineers is embedded into the system the knowledge will be lost in the future. A production process is described in a proposed format similar to BOM and the process can be retrieved as a flow diagram to make the engineers to understand the product and process. Proposed method is applied to a simple production process of common sub-assembly of ships for evaluation. Keywords: Production process, DFM, Ontology, Computer system 1 INTRODUCTION (Unified Resource Identifier) is assigned to all the objects, There are many research and computer program for and metadata is defined for all objects using the URI. supporting optimization of production process in Metadata is defined as a statement with subject, shipyards. And knowledge of experienced engineers is predicate and object. The statement is called triple in embedded into the system. Once the knowledge is RDF. Two kinds of elements, Literal or Resource, can be embedded into computer system, the knowledge is not a component of a statement.
    [Show full text]
  • Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes
    Using Telelogic DOORS and Microsoft Visio to Model and Visualize Complex Business Processes “The Business Driven Application Lifecycle” Bob Sherman Procter & Gamble Pharmaceuticals [email protected] Michael Sutherland Galactic Solutions Group, LLC [email protected] Prepared for the Telelogic 2005 User Group Conference, Americas & Asia/Pacific http://www.telelogic.com/news/usergroup/us2005/index.cfm 24 October 2005 Abstract: The fact that most Information Technology (IT) projects fail as a result of requirements management problems is common knowledge. What is not commonly recognized is that the widely haled “use case” and Object Oriented Analysis and Design (OOAD) phenomenon have resulted in little (if any) abatement of IT project failures. In fact, ten years after the advent of these methods, every major IT industry research group remains aligned on the fact that these projects are still failing at an alarming rate (less than a 30% success rate). Ironically, the popularity of use case and OOAD (e.g. UML) methods may be doing more harm than good by diverting our attention away from addressing the real root cause of IT project failures (when you have a new hammer, everything looks like a nail). This paper asserts that, the real root cause of IT project failures centers around the failure to map requirements to an accurate, precise, comprehensive, optimized business model. This argument will be supported by a using a brief recap of the history of use case and OOAD methods to identify differences between the problems these methods were intended to address and the challenges of today’s IT projects.
    [Show full text]
  • Course Structure & Syllabus of B.Tech Programme In
    Course Structure & Syllabus of B.Tech Programme in Information Technology (From the Session 2015-16) VSSUT, BURLA COURSE STRUCTURE FIRST YEAR (COMMON TO ALL BRANCHES) FIRST SEMESTER SECOND SEMESTER Contact Contact Theory Hrs. Theory Hrs. CR CR Course Course Subject L .T .P Subject L. T. P Code Code Mathematics-I 3 - 1 - 0 4 Mathematics-II 3 - 1 - 0 4 Physics/Chemistry 3 - 1 - 0 4 Chemistry/ Physics 3 - 1 - 0 4 Engineering Computer /CS15- CS15- Mechanics/Computer 3 - 1 - 0 4 Programming/Engineering 3 - 1 - 0 4 008 008/ Programming Mechanics Basic Electrical Engineering/ Basic Electronics/Basic 3 - 1 - 0 4 3 - 1 - 0 4 Basic Electronics Electrical Engineering English/Environmental Environmental 3 - 1 - 0 4 3 - 1 - 0 4 Studies Studies/English Sessionals Sessionals Physics Laboratory/ Chemistry Lab/ Physics 0 - 0 - 3 2 0 - 0 - 3 2 Chemistry Lab Laboratory Workshop-I/Engineering Engineering Drawing/ 0 - 0 - 3 2 0 - 0 - 3 2 Drawing Workshop-I Basic Electrical Engineering Basic Electronics Lab/Basic 0 - 0 - 3 2 0 - 0 - 3 2 Lab/Basic Electronics Lab Electrical Engineering Lab Business Communication Programming Lab/ /CS15- CS15- and Presentation Skill/ 0 - 0 - 3 2 Business Communication 0 - 0 - 3 2 984 984/ Programming Lab and Presentation Skill Total 15-5-15 28 Total 15-5-15 28 SECOND YEAR THIRD SEMESTER FOURTH SEMESTER Contact Contact Theory Hrs. Theory Hrs. CR CR Course Subject L .T .P Course Code Subject L. T. P Code Mathematics-III Computer Organization 3 - 1 - 0 4 CS15-007 and Architecture 3 - 1 - 0 4 Digital Systems 3 - 1 - 0 4 CS15-032 Theory
    [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]
  • The Unified Modeling Language Reference Manual
    The Unified Modeling Language Reference Manual The Unified Modeling Language Reference Manual James Rumbaugh Ivar Jacobson Grady Booch ADDISON-WESLEY An imprint of Addison Wesley Longman, Inc. Reading, Massachusetts • Harlow, England • Menlo Park, California Berkeley, California • Don Mills, Ontario • Sydney Bonn • Amsterdam • Tokyo • Mexico City Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial caps or all caps. Unified Modeling Language, UML, and the UML cube logo are trademarks of the Object Management Group. Some material in this book is derived from the Object Management Group UML Specification documentation. Used by permission of the Object Management Group. The authors and publisher have taken care in the preparation of this book but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for special sales. For more information, please contact: AWL Direct Sales Addison Wesley Longman, Inc. One Jacob Way Reading, Massachusetts 01867 (781) 944-3700 Visit AW on the Web: www.awl.com/cseng/ Library of Congress Cataloging-in-Publication Data Rumbaugh, James. The unified modeling language reference manual / James Rumbaugh, Ivar Jacobson, Grady Booch. p. cm. — (The Addison-Wesley object technology series) Includes bibliographical references and index.
    [Show full text]
  • A Brief History of Devops by Alek Sharma Introduction: History in Progress
    A Brief History of DevOps by Alek Sharma Introduction: History in Progress Software engineers spend most of their waking hours wading George Santayana wrote that “those who cannot remember the through the mud of their predecessors. Only a few are lucky past are condemned to repeat it.” He was definitely not thinking enough to see green fields before conflict transforms the about software when he wrote this, but he’s dead now, which terrain; the rest are shipped to the front (end). There, they means he can be quoted out of context. Oh, the joys of public languish in trenches as shells of outages explode around them. domain! Progress is usually glacial, though ground can be covered This ebook will be about the history of software development through heroic sprints. methodologies — especially where they intersect with traditional best practices. Think of it as The Silmarillion of Silicon Valley, But veterans do emerge, scarred and battle-hardened. They except shorter and with more pictures. Before plunging into this revel in relating their most daring exploits and bug fixes to new rushing river of time, please note that the presented chronology recruits. And just as individuals have learned individual lessons is both theoretically complete and practically in progress. In other about writing code, our industry has learned collective lessons words, even though a term or process might have been coined, it about software development at scale. It’s not always easy to always takes more time for Best Practices to trickle down to Real see these larger trends when you’re on the ground — buried in Products.
    [Show full text]
  • Multicore Programming
    PlantUML 040coders.nl 2020-02-20 Klaas van Gend Klaas van Gend C++ UML and software tools The Three Amigos Grady Booch James Rumbaugh Ivar Jacobson Rational 1981-2008 DEC early 60s-1968 Ericsson 1962-1995 IBM “Generic” 2008-now GE Research 1968-94 (Objectory 1987-1991/5) (OMT) Rational 1995-2003 Rational 1994-2006 Ivar Jacobson Intl 2003-now Retired UML Predecessors UML Diagram Behaviour Structure Diagram Diagram Activity State Class Component Object Diagram Machine Diagram Diagram Diagram Diagram Interaction Use Case Composite Deployment Package Profile Diagram Diagram Structure Diagram Diagram Diagram Diagram Communication Interaction Sequence Timing Diagram Overview Diagram Diagram Notation: UML Diagram What UML is ● A language to describe what elements in an image mean ● intended to provide a standard way to visualize the design of a system What UML is not ● A software analysis methodology ● A software design methodology ● A programming language ● Free from dialects and heated debates UML False Promises ● Design and code are interchangeable – a.k.a. “reverse engineering” – a.k.a. “round-trip engineering” ● Easily generate your code from the design – Every MDD tool needs additional work/code – ‘Glue code’ tends to be painful ● Fool-proof – No, fools still make beautiful but bad designs ● Time saving A few visual UML tools Rational Rose Rational Rose RT Rational Rose Modeling XDE Rational Software Architect ArgoUML Rational Software Architect RTE Rational Rhapsody Visio Together StarUML Umbrello PlantUML PlantUML Demo ● Turn simple text
    [Show full text]
  • IX. Use Cases the Unified Modeling Language (UML)
    Information Systems Analysis and Design csc340 IX. Use Cases The Unified Modeling Language Actors and Use Cases How to Find Them 2004 John Mylopoulos Use Cases -- 1 Information Systems Analysis and Design csc340 The Unified Modeling Language (UML) Booch and Rumbaugh started working towards a unified modelling language (UML) in 1994 under the auspices of Rational Inc. They were later joined by Jacobson. UML only offers a notation, not a methodology for modeling (as various OOA techniques do). Combines Jacobson’s use cases with Booch and Rumbaugh concepts for object modeling, along with statecharts. UML has been adopted by the Object Management Group {OMG) as an (object) modelling standard. OMG UML 1.0 is the first version of this new modelling standard. 2004 John Mylopoulos Use Cases -- 2 Page ‹#› Information Systems Analysis and Design csc340 Where Do We Start? Use Cases Use cases describe how the system-to-be (or any artifact under design, for that matter!) from a user’s perspective. They answer the question: How will the artifact be used, once it is built? Used to show the functions to be supported. Developed by Ivar Jacobson and friends [Jacobson92]. 2004 John Mylopoulos Use Cases -- 3 Information Systems Analysis and Design csc340 Actors An actor is anything that needs to exchange information with the artifact An actor could be a person, or another external, system. Actors define roles that users can play while using the artifact. Campaign Manager Staff Contact Accountant 2004 John Mylopoulos Use Cases -- 4 Page ‹#› Information Systems Analysis and Design csc340 Use Cases A use case is a function the new system needs to support.
    [Show full text]
  • Enhancing Scaled Agility with Use Case 2.0 and BDD Gherkin
    Enhancing Scaled Agility with Use Case 2.0 and BDD Gherkin Bernard F. Clark1 Introduction In this article I base my observations and opinions on my experience of applying the Use Case 2.0 Practice and Behavior Driven Development’s Gherkin language, within an online products division of a major US Bank that is undergoing an Agile transformation. “I’m not dead yet,” Is a classic line from the movies that Monty Python fans will instantly recognize. I start with this because I could win a lot of money betting on the response from Agile practitioners when I tell them I am using Use Cases in an Agile environment to great benefit. “Use Cases? They’re dead and buried!” “That’s RUP! (Rational Unified Process). They aren’t agile.” “What are you thinking? Use Cases are dinosaurs.” “You should know better, Bernie.” Rarely, I get a response from an experienced coach who will not poke fun, but seek the powerful questions such as, “Now why do you think that’s a good idea?”, and a valuable conversation ensues. A Very Brief History Use Cases were invented in 1986 by Dr. Ivar Jacobson for the purpose of defining the required interactions and responsibilities of a user of a system and that system, in order to achieve a specific goal; e.g. ‘Open an Account’. You can think of them as large User Stories that contain multiple possible scenarios for achieving the goal or handling errors. In one scenario, the Use Case proceeds though each step without incident (Happy Path). In another scenario, the Use Case describes an Alternative Flow for handling a special circumstance.
    [Show full text]
  • Use Case Modeling
    INF5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 7: 27.02.2017 Arne-Jørgen Berre [email protected] or [email protected] Telecom and Informatics 1 Course parts (16 lectures) - 2017 January (1-3) (Introduction to Modeling, Business Architecture and the Smart Building project): 1-16/1: Introduction to INF5120 2-23/1: Modeling structure and behaviour (UML and UML 2.0 and metamodeling) - (establish Oblig groups) 3-30/1: WebRatio for Web Apps/Portals and Mobile Apps – and Entity/Class modeling – (Getting started with WebRatio) February (4-7) (Modeling of User Interfaces, Flows and Data model diagrams, Apps/Web Portals - IFML/Client- Side): 4-6/2: Business Model Canvas, Value Proposition, Lean Canvas and Essence 5-13/2: IFML – Interaction Flow Modeling Language, WebRatio advanced – for Web and Apps 6-20/2: BPMN process, UML Activ.Diagrams, Workflow and Orchestration modelling value networks 7-27/2: Modeling principles – Quality in Models 27/2: Oblig 1: Smart Building – Business Architecture and App/Portal with IFML WebRatio UI for Smart Building March (8-11) (Modeling of IoT/CPS/Cloud, Services and Big Data – UML SM/SD/Collab, ThingML Server-Side): 8-6/3: DSL and ThingML, UML State Machines and Sequence Diagrams 9-13/3: UML Composite structures, State Machines and Sequence Diagrams II 10-20/3: Architectural models, Role modeling and UML Collaboration diagrams 11-27/3: UML Service Modeling, ServiceML,SoaML, REST, UML 2.0 Composition, MagicDraw 27/3: Oblig 2: Smart Building – Internet of Things control with ThingML – Raspberry Pi, Wireless sensors (temperature, humidity), actuators (power control) April/May (12-14) (MDE – Creating Your own Domain Specific Language): 12-3/4: Model driven engineering – Metamodels, DSL, UML Profiles, EMF, Sirius Editors EASTER – 10/4 og 17/4 13-24/4: MDE transformations, Non Functional requirements 1.
    [Show full text]