DOCSLIB.ORG

07 Requirements What About RFP/RFB/Rfis?

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

CMPSCI520/620 07 Requirements & UML Intro 07 Requirements SW Requirements Specification • Readings • How do we communicate the Requirements to others? • [cK99] Cris Kobryn, Co-Chair, “Introduction to UML: Structural and Use Case Modeling,” UML Revision Task Force Object Modeling with OMG UML Tutorial • It is common practice to capture them in an SRS Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea Data, • But an SRS doesn’t need to be a single paper document Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • Purpose • [OSBB99] Gunnar Övergaard, Bran Selic, Conrad Bock and Morgan Björkande, “Behavioral Modeling,” UML Revision Task Force, Object Modeling with OMG UML • Contractual requirements Tutorial Series © 1999-2001 OMG and Contributors: Crossmeta, EDS, IBM, Enea elicitation Data, Hewlett-Packard, IntelliCorp, Kabira Technologies, Klasse Objecten, Rational • Baseline Software, Telelogic, Unisys http://www.omg.org/technology/uml/uml_tutorial.htm • for evaluating subsequent products • [laM01] Maciaszek, L.A. (2001): Requirements Analysis and System Design. • for change control requirements Developing Information Systems with UML, Addison Wesley Copyright © 2000 by analysis Addison Wesley • Audience • [cB04] Bock, Conrad, Advanced Analysis and Design with UML • Users, Purchasers requirements http://www.kabira.com/bock/ specification • [rM02] Miller, Randy, “Practical UML: A hands-on introduction for developers,” • Systems Analysts, Requirements Analysts Copyright © 2002 TogetherSoft, Inc. [now at Borland site] • Developers, Programmers http://bdn.borland.com/article/0,1410,31863,00.html requirements • Testers validation • Project Managers UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 What about RFP/RFB/RFIs? Appropriate Specification • RFP = ‘SRS’ written by the procurer (or by an • Consider two different projects: independent RE contractor) • Tiny project, 1 programmer, 2 months work • Selected developer may create a more detailed ‘SRS’ • Programmer talks to customer, then writes up a 5-page memo • developer’s understanding of the customers needs • Large project, 50 programmers, 2 years work • basis for evaluation of contractual performance • Team of analysts model the requirements, then document • Not typically response to RFP them in a 500-page SRS • IEEE Standard recommends SRS jointly developed by Project A Project B procurer and developer Purpose of spec? Crystalizes programmer’s Build-to document; must understanding; feedback to contain enough detail for all • When to issue RFP/RFB? customer the programmers Management Spec is irrelevant; have Will use the spec to estimate • Early (conceptual stage) view? already allocated resource needs and plan the resources development • Late (detailed specification stage) Readers? Primary: Spec author; Primary: programmers, Secondary: Customer testers, managers; Secondary: customers UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 1 CMPSCI520/620 07 Requirements & UML Intro Hints & Guidelines There is no Perfect SRS • Validity (or “correctness”) • Ambiquity • expresses only the real needs of • every statement can be read in condense the stakeholders (customers, exactly one way users,…) • defines confusing terms ambiguousambiguous • Completeness • e.g. in a glossary • specifies all the things the system • Verifiablility expand must do and all the things it must • includes a process exists to test not do! satisfaction of each requirement expand • Conceptual Completeness • every requirement is specified • e.g. responses to all classes of input behaviorally • Structural Completeness • Understandablility (Clarity) redundantredundant formalize inconsistentinconsistent • e.g. no “to be determined” functions • e.g. by non-computer specialists • Consistency • technical notations should only be • not self-contradictory used as backup (e.g. in an reduce add • satisfiable appendix) explanations resolve • all terms used consistently • Modifiability not • inconsistency can be hard to • easy to change and modify not detect especially in timing aspects • good structure and cross- understandableunderstandable and business logic referencing incompleteincomplete • Necessary • must be kept up to date! • doesn’t contain anything that isn’t “required” see IEEE-STD-830-1993 © Steve Easterbrook 2000-2002 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Typical mistakes IEEE std offers different templates • Noise • Jigsaw puzzles • External stimulus or external situation • text that carries no relevant • distributing key information across • e.g., for an aircraft landing system, each information to any feature of the a document and then cross- 1.Introduction different type of landing situation: wind gusts, no problem. referencing 1.Introduction fuel, short runway, etc • Purpose • Silence • Duckspeak requirements • Purpose • System feature •• ScopeScope • e.g., for a telephone system: call forwarding, call • a feature that is not covered by • requirements that are only there to • Definitions, acronyms, abbreviations blocking, conference call, etc any text. conform to standards • Definitions, acronyms, abbreviations • Reference documents • System response Over-specification Unnecessary invention of terminology • Reference documents • • • Overview • e.g., for a payroll system: generate pay-cheques, • text that describes a feature of the • e.g. ‘user input presentation • Overview report costs, print tax info; 2.Overall Description solution, rather than the problem. function’ 2.Overall Description • External object • Contradiction • e.g. ‘airplane reservation data •• ProductProduct perspective perspective • e.g. for a library information system, organize by • text that defines a single feature in validation function’ •• ProductProduct functions functions book type a number of incompatible ways. • Inconsistent terminology •• UserUser characteristics characteristics • User type • Ambiguity • inventing and then changing • Constraints • e.g. for a project support system: manager, • Constraints technical staff, administrator, etc. • text that can be interpreted in at terminology • Assumptions and Dependencies • Assumptions and Dependencies • Mode least two different ways. • Putting the onus on the development 3.Specific Requirements staff 3.Specific Requirements • e.g. for word processor: page layout mode, • Forward reference outline mode, text editing mode, etc • i.e. making the reader work hard to Appendices • text that refers to a terms or Appendices • Object features yet to be defined. decipher the intent Index Index • e.g., in a patient monitorng system, objects • Wishful thinking • Writing for the hostile reader include patients, sensors, nurses, rooms, • text that defines a feature that • fewer of these than friendly physicians, medicines, etc. cannot possibly be validated. readers from Steve Easterbrook © 2000-2002; he adapted from Kovitz, 1999 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 2 CMPSCI520/620 07 Requirements & UML Intro Maciaszek vs. IEEE SRS using a UML “package” construct 1.1.IntroductionIntroduction •• PurposePurpose •• ScopeScope •• Definitions,Definitions, acronyms, acronyms, abbreviations abbreviations •• ReferenceReference documents documents •• OverviewOverview 2.2.OverallOverall Description Description •• ProductProduct perspective perspective •• ProductProduct functions functions •• UserUser characteristics characteristics •• ConstraintsConstraints •• AssumptionsAssumptions and and Dependencies Dependencies 3.3.SpecificSpecific Requirements Requirements Appendices Appendices Index Index Probasco and Leffingwell Rational Software UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 SRS using a UML “package” construct UML & SRS • SRS • may include a single document, multiple documents, use case specifications and even the graphical use case model which describes relationships amongst the use cases. • Stakeholders • system analyst • use-case specifier • designers • implementers • project manager • testers • Features Drive Use Case Models “Combining Software Requirements Specifications with Use-Case Modeling,” Use Cases Interpret Leslee Probasco and Dean Leffingwell Requirements www.spc.ca/downloads/srs_usecase.doc UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 UNIVERSITY OF MASSACHUSETTS AMHERST • DEPARTMENT OF COMPUTER SCIENCE • CMPSCI 520/620 FALL 2004 Rick Adrion 2004 (except where noted) 3 CMPSCI520/620 07 Requirements & UML Intro Example SRS format and style • openCMSstruts • Modifiability • http://opencmsstruts.sourceforge.net/vision.html • well-structured, indexed, cross-referenced, etc. • redundancy should be avoided or must
Recommended publications
  • Blurred Lines Between Role and Reality: a Phenomenological Study of Acting

    Blurred Lines Between Role and Reality: a Phenomenological Study of Acting

    Antioch University AURA - Antioch University Repository and Archive Student & Alumni Scholarship, including Dissertations & Theses Dissertations & Theses 2019 Blurred Lines Between Role and Reality: A Phenomenological Study of Acting Gregory Hyppolyte Brown Follow this and additional works at: https://aura.antioch.edu/etds Part of the Psychology Commons BLURRED LINES BETWEEN ROLE AND REALITY: A PHENOMENOLOGICAL STUDY OF ACTING A Dissertation Presented to the Faculty of Antioch University Santa Barbara In partial fulfillment of the requirements for the the degree of DOCTOR OF PSYCHOLOGY In CLINICAL PSYCHOLOGY by GREGORY HIPPOLYTE BROWN August 2019 This dissertation, by Gregory Hippolyte Brown, has been approved by the committee members signed below who recommend that it be accepted by the faculty of Antioch University Santa Barbara in partial fulfillment of requirements for the degree of DOCTOR OF PSYCHOLOGY Dissertation Committee: _________________________ Brett Kia-Keating, Ed.D. Chairperson __________________________ Sharleen O‘ Brien, Ph.D. Second Faculty __________________________ Thalia R. Goldstein, Ph.D. External Expert ii Copyright © 2019 Gregory Hippolyte Brown iii Abstract When an actor plays a character in a film, they try to connect with the emotions and behavioral patterns of the scripted character. There is an absence of literature regarding how a role influences an actor’s life before, during, and after film production. This study examined how acting roles might influence an actor during times on set shooting a movie or television series as well as their personal life after the filming is finished. Additionally the study considered the psychological impact of embodying a role, and whether or not an actor ever has the feeling that the performed character has independent agency over the actor.
  • OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007

    OMG Systems Modeling Language (OMG Sysml™) Tutorial 25 June 2007

    OMG Systems Modeling Language (OMG SysML™) Tutorial 25 June 2007 Sanford Friedenthal Alan Moore Rick Steiner (emails included in references at end) Copyright © 2006, 2007 by Object Management Group. Published and used by INCOSE and affiliated societies with permission. Status • Specification status – Adopted by OMG in May ’06 – Finalization Task Force Report in March ’07 – Available Specification v1.0 expected June ‘07 – Revision task force chartered for SysML v1.1 in March ‘07 • This tutorial is based on the OMG SysML adopted specification (ad-06-03-01) and changes proposed by the Finalization Task Force (ptc/07-03-03) • This tutorial, the specifications, papers, and vendor info can be found on the OMG SysML Website at http://www.omgsysml.org/ 7/26/2007 Copyright © 2006,2007 by Object Management Group. 2 Objectives & Intended Audience At the end of this tutorial, you should have an awareness of: • Benefits of model driven approaches for systems engineering • SysML diagrams and language concepts • How to apply SysML as part of a model based SE process • Basic considerations for transitioning to SysML This course is not intended to make you a systems modeler! You must use the language. Intended Audience: • Practicing Systems Engineers interested in system modeling • Software Engineers who want to better understand how to integrate software and system models • Familiarity with UML is not required, but it helps 7/26/2007 Copyright © 2006,2007 by Object Management Group. 3 Topics • Motivation & Background • Diagram Overview and Language Concepts • SysML Modeling as Part of SE Process – Structured Analysis – Distiller Example – OOSEM – Enhanced Security System Example • SysML in a Standards Framework • Transitioning to SysML • Summary 7/26/2007 Copyright © 2006,2007 by Object Management Group.
  • PART 3: UML Dynamic Modelling Notations • State Machines/Statecharts • Collaboration Diagrams • Sequence Diagrams • Activity Diagrams

    PART 3: UML Dynamic Modelling Notations • State Machines/Statecharts • Collaboration Diagrams • Sequence Diagrams • Activity Diagrams

    PART 3: UML Dynamic Modelling Notations • State machines/statecharts • Collaboration diagrams • Sequence diagrams • Activity diagrams. Chapter 19 of the textbook is relevant to this part. 1 State machines • State machines describe dynamic behaviour of objects, show life history of objects over time + object communications. • Used for real-time system design (eg., robotics); GUI design (states represent UI screens/modes). Example shows simple state machine with two states, On and Off and transitions between them. 2 Switch Off swon swoff On Simple state machine 3 State machines Elements of a state machine are: States: Rounded-corner boxes, containing state name. Transitions: Arrows from one state, source of transition, to another, target, labelled with event that causes transition. Default initial state: State of object at start of its life history. Shown as target of transition from initial pseudostate (black filled circle). Termination of state machine can be shown by `bullseye' symbol. 4 State machines UML divides state machines into two kinds: 1. Protocol state machines { describe allowed life histories of objects of a class. Events on transitions are operations of that class, transitions may have pre and post conditions. Transitions cannot have generated actions (although we will allow this). 2. Behaviour state machines { describe operation execution/implementation of object behaviour. Transitions do not have postconditions, but can have actions. State machines describe behaviour of objects of a particular class, or execution processing of an operation. 5 State machines • Class diagrams describe system data, independently of time. • State machines show how system/objects can change over time. • Switch state machine is protocol state machine for objects of Switch class.
  • UML Tutorial: Sequence Diagrams

    UML Tutorial: Sequence Diagrams

    UML Tutorial: Sequence Diagrams. Robert C. Martin Engineering Notebook Column April, 98 In my last column, I described UML Collaboration diagrams. Collaboration diagrams allow the designer to specify the sequence of messages sent between objects in a collaboration. The style of the diagram emphasizes the relationships between the objects as opposed to the sequence of the messages. In this column we will be discussing UML Sequence diagrams. Sequence diagrams contain the same information as Collaboration diagrams, but emphasize the sequence of the messages instead of the relationships between the objects. The Cellular Phone Revisited Here again is the final collaboration diagram from last column’s Cellular Phone example. (See Figure 1.) 1*:ButtonPressed() :DigitButton Digit:Button 1.1:Digit(code) Adapter 2:ButtonPressed() :SendButton Send:Button :Dialler Adapter 2.1:Send() 1.1.2:EmitTone(code) 2.1.1:Connect(pno) 1.1.1:DisplayDigit(code) 2.1.1.1:InUse() :Cellular display display:Dialler :Speaker Radio :CRDisplay Display Figure 1: Collaboration diagram of Cellular Phone. The Sequence diagram that corresponds to this model is shown in Figure 2. It is pretty easy to see what the diagrams in Figure 2 are telling us, especially when we compare them to Figure 1. Let’s walk through the features. First of all, there are two sequence diagrams present. The first one captures the course of events that takes place when a digit button is pressed. The second captures what happens when the user pushes the ‘send’ button in order to make a call. At the top of each diagram we see the rectangles that represent objects.
  • Sysml, the Language of MBSE Paul White

    Sysml, the Language of MBSE Paul White

    Welcome to SysML, the Language of MBSE Paul White October 8, 2019 Brief Introduction About Myself • Work Experience • 2015 – Present: KIHOMAC / BAE – Layton, Utah • 2011 – 2015: Astronautics Corporation of America – Milwaukee, Wisconsin • 2001 – 2011: L-3 Communications – Greenville, Texas • 2000 – 2001: Hynix – Eugene, Oregon • 1999 – 2000: Raytheon – Greenville, Texas • Education • 2019: OMG OCSMP Model Builder—Fundamental Certification • 2011: Graduate Certification in Systems Engineering and Architecting – Stevens Institute of Technology • 1999 – 2004: M.S. Computer Science – Texas A&M University at Commerce • 1993 – 1998: B.S. Computer Science – Texas A&M University • INCOSE • Chapters: Wasatch (2015 – Present), Chicagoland (2011 – 2015), North Texas (2007 – 2011) • Conferences: WSRC (2018), GLRCs (2012-2017) • CSEP: (2017 – Present) • 2019 INCOSE Outstanding Service Award • 2019 INCOSE Wasatch -- Most Improved Chapter Award & Gold Circle Award • Utah Engineers Council (UEC) • 2019 & 2018 Engineer of the Year (INCOSE) for Utah Engineers Council (UEC) • Vice Chair • Family • Married 14 years • Three daughters (1, 12, & 10) 2 Introduction 3 Our Topics • Definitions and Expectations • SysML Overview • Basic Features of SysML • Modeling Tools and Techniques • Next Steps 4 What is Model-based Systems Engineering (MBSE)? Model-based systems engineering (MBSE) is “the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases.” -- INCOSE SE Vision 2020 5 What is Model-based Systems Engineering (MBSE)? “Formal systems modeling is standard practice for specifying, analyzing, designing, and verifying systems, and is fully integrated with other engineering models. System models are adapted to the application domain, and include a broad spectrum of models for representing all aspects of systems.
  • Modelling Interactions

    Modelling Interactions

    University of Toronto Department of Computer Science Lecture 15: Modelling System Interactions Interactions with the new system How will people interact with the system? When/Why will they interact with the system? Use Cases introduction to use cases identifying actors identifying cases Advanced features Sequence Diagrams Temporal ordering of events involved in a use case © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 1 University of Toronto Department of Computer Science Moving towards specification What functions will the new system provide? How will people interact with it? Describe functions from a user’s perspective UML Use Cases Used to show: the functions to be provided by the system which actors will use which functions Each Use Case is: a pattern of behavior that the new system is required to exhibit a sequence of related actions performed by an actor and the system via a dialogue. An actor is: anything that needs to interact with the system: a person a role that different people may play another (external) system. © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 2 University of Toronto Department of Computer Science Use Case Diagrams Capture the relationships between actors and Use Cases Change a client contact Campaign Staff contact Manager Add a new client Record client payment Accountant © 2004-5 Steve Easterbrook. This presentation is available free for non-commercial use with attribution under a creative commons license. 3 University of Toronto Department of Computer Science Notation for Use Case Diagrams Use case Change client contact Staff contact Actor Communication association System boundary © 2004-5 Steve Easterbrook.
  • Plantuml Language Reference Guide (Version 1.2021.2)

    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
  • Methodological and Analytical Expertise in Socio-Technological

    Methodological and Analytical Expertise in Socio-Technological

    Paper prepared for the Conference Proceedings of the International System Dynamics Conference in Washington DC USA, July, 2011 How does the Multi-Level Perspective help to enhance a System Dynamics analysis of a specific transition challenge? Silvia Ulli-Beer 1, Stefan Grösser 2 and Alexander Wokaun 1 [email protected] ; [email protected] ; [email protected] 1Paul Scherrer Institut, Dynamics of Innovative Systems, 5232 Villigen PSI, Switzerland 2University of St. Gallen, Institute of Management (IfB), Dufourstrasse 40a, 9000 St. Gallen, Switzerland 2University of Bern, Interdisciplinary Center for General Ecology (IKAÖ), Schanzeneckstr. 1, 3001 Bern, Switzerland Abstract This paper addresses the challenge of identifying adequate theoretical starting points for problem oriented simulation studies of socio-technical transitions towards near fossil free energy services e.g. for housing and transportation. The identification of adequate starting points for simulation studies is becoming increasingly important for the generalization of simulation results as well as for theory refinement. We found that the Multi-Level Perspective (MLP) offers a helpful language for a modelling experiment based in a feedback perspective. This allows the conceptualization of a socio-technical transition challenge departing from an inter-subjective and hence scientific starting point. In addition feedback modelling appears to be a promising mathematical analysis approach that helps to substantiate the MLP. We have seen that the insights of the simulation experiment corroborate basic assumptions of the MLP concerning multi-level alignment processes but also discriminate the decisive determinants and governance mechanisms that explain radical innovation and subsequently the creation of path dependency. 1. Introduction This paper addresses the challenge of identifying adequate theoretical starting points for problem oriented simulation studies of socio-technical transitions towards near fossil free energy services e.g.
  • Define Your Project and System Requirements - a Guide for Program Managers and Directors

    Define Your Project and System Requirements - a Guide for Program Managers and Directors

    Define your project and system requirements - A guide for program managers and directors Disease Surveillance [epidemic determined] Notify Local Health Dept. [no significant activity] Assess Sensitivity of Measurement Georgia Department of Human Resources Division of Public Health Office of Health Information & Policy Define your project and system requirements - A guide for program managers and directors Disease Surveillance [epidemic determined] Notify Local Health Dept. [no significant activity] Assess Sensitivity of Measurement A synopsis of Applying Use Cases, Prepared by Gordon R. Freymann, MPH Office of Health Information & Policy Division of Public Health Georgia Department of Human Resources Publication # DPH02.92 Office of Health Information & Policy Division of Public Health Georgia Department of Human Resources Page 2 of 18 Define your project and system requirements - A guide for program managers and directors Inception Phase .......................................................................................................... 3 Identifying system boundaries...................................................................................... 4 Identifying Actors........................................................................................................ 4 Identifying Use Cases ...................................................................................... ........... 4 Elaboration Phase ....................................................................................................... 6 Primary
  • Chapter 5 – Extending the Requirements Models Solutions to End-Of-Chapter Problems

    Chapter 5 – Extending the Requirements Models Solutions to End-Of-Chapter Problems

    Systems Analysis and Design in a Changing World, sixth edition 5-1 Chapter 5 – Extending the Requirements Models Solutions to End-of-Chapter Problems Review Questions 1. What are the models that describe use cases in more detail? Fully developed use case description, activity diagrams, and system sequence diagrams. 2. What two UML diagrams are used to model domain classes? Problem domain class diagram and state machine diagram. 3. Which part of a use case description can also be modeled by using an activity diagram? The “flow of activities” section. 4. Explain the difference between a use case and a scenario. Give a specific example of a use case with a few possible scenarios. A use case is the entire function or user goal or event. A scenario is one specific version or instance of that use case. From RMO we have Create customer account as a use case. But we might have Create online Customer account and Create instore customer account and even Create phone customer account as different scenarios. 5. List the parts or compartments of a fully developed use case description. Use case name Scenario Triggering event Brief description Actors Related use cases Stakeholders Preconditions Postconditions Flow of activities Exception conditions 6. Compare/contrast precondition and postcondition. A precondition describes the “states” of data and the system that must exist before the use case can begin. For example to add an item to a shopping cart, the item must exist in the database. A postcondition describes the states of data and the system that must exist after the use case completes.
  • UML 2001: a Standardization Odyssey

    UML 2001: a Standardization Odyssey

    UML 2001: A Standardization Odyssey As the UML reaches the ripe age of four, both its proponents and its critics are scanning the recent changes in the UML 1.3 revision. CRIS KOBRYN In a relatively short period of time the Unified Modeling Language has emerged as the software industry’s dominant modeling language. UML is not only a de facto modeling language standard; it is fast becoming a de jure standard. Nearly two years ago the Object Management Group (OMG) adopted UML as its standard modeling language. As an approved Publicly Available Specification (PAS) submitter to the International Organization for Standardization (ISO), the OMG is proposing the UML specification for international timescales of standards usually conflict with the standardization. It is anticipated that the “fast competitive need to use the latest technology as track” PAS process will complete sometime next early as possible. From a technical perspective, the year, at which time UML will be formally recog- need to achieve consensus encourages “design by nized as an international standard for information committee” processes. In this sort of environment, technology. sound technical tradeoffs are often overridden by The major benefits of international standardiza- inferior political compromises. Too frequently the tion for a specification include wide recognition and resulting specifications become bloated with patches acceptance, which typically enlarge the market for in a manner similar to the way laws become fattened products based on it. However, these benefits often with riders in “pork belly” legislation. demand a high price. Standardization processes are This article explores how the UML is faring in typically formal and protracted, seeking to accom- the international standardization process.
  • UML Why Develop a UML Model?

    UML Why Develop a UML Model?

    App Development & Modelling BSc in Applied Computing Produced Eamonn de Leastar ([email protected]) by Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie Introduction to UML Why develop a UML model? • Provide structure for problem solving • Experiment to explore multiple solutions • Furnish abstractions to manage complexity • Decrease development costs • Manage the risk of mistakes #3 The Challenge #4 The Vision #5 Why do we model graphically? " Graphics reveal data.! " Edward Tufte$ The Visual Display of Quantitative Information, 1983$ " 1 bitmap = 1 megaword.! " Anonymous visual modeler #6 Building Blocks of UML " The basic building blocks of UML are:! " model elements (classes, interfaces, components, use cases, etc.)! " relationships (associations, generalization, dependencies, etc.)! " diagrams (class diagrams, use case diagrams, interaction diagrams, etc.)! " Simple building blocks are used to create large, complex structures! " eg elements, bonds and molecules in chemistry! " eg components, connectors and circuit boards in hardware #7 Example : Classifier View #8 Example: Instance View #9 UML Modeling Process " Use Case! " Structural! " Behavioural! " Architectural #10 Use Case Visual Paradigm Help #11 Structural Modeling Visual Paradigm Help #12 Behavioural Modeling Visual Paradigm Help #13 Architectural Modeling Visual Paradigm Help #14 Structural Modeling " Core concepts! " Diagram Types #15 Structural Modeling Core Elements " a view of an system that emphasizes