Objectives Pre-Test Questions Introduction Collaboration Diagrams Flow of Events and Special Requirements...
|
|
- Todd Sims
- 5 years ago
- Views:
Transcription
1 10 Analysis Modeling M MAJOR A J O R T TOPICSO P I C S Objectives Pre-Test Questions Introduction Collaboration Diagrams Flow of Events and Special Requirements Class-Responsibility-Collaboration Cards Class Analysis When Is This Useful Summary Post-Test Questions
2 144 Chapter 10 Analysis Modeling OBJECTIVES At the completion of this chapter, you will be able to: Interpret collaboration diagrams. Create collaboration diagrams to illustrate a rough vision of system design. Create flow-of-events descriptions to accompany collaboration diagrams. Use CRC cards to aid in developing collaboration diagrams. Identify attributes. Identify aggregation and generalization relationships. PRE-TEST QUESTIONS The answers to these questions are in Appendix A at the end of this manual. 1. What do collaboration diagrams illustrate? 2. What is a sequence diagram? 3. What are CRC cards?
3 Introduction 145 INTRODUCTION In the preceding chapter, you were introduced to the three UML class stereotypes: boundary, entity, and control. Boundary classes form the interface between a system and its users. Entity classes represent data and real-life objects, and control classes represent the actions and processes not represented in boundary or entity classes. In this chapter, you will learn to combine these class types into collaboration diagrams. UML collaboration diagrams describe, in a precise manner, the dynamics of a software s function and represent this information using automated processes. As a programmer, collaboration diagrams provide simplified access to the functionality of a program, therefore, providing timely and robust error analysis with improved options for system upgrades. COLLABORATION DIAGRAMS Collaboration diagrams are a form of an interaction diagram that are used within the analysis workflow to provide an overview of a system's design. They describe the interaction between users and boundary classes and between classes themselves. Figure 10-1 is a portion of a collaboration diagram for the Check Out Asset use case. In this example, a Librarian actor interacts with a boundary class, Check Out UI. 1: Select patron(patronid) : Librarian : Check Out UI Figure 10-1: Collaboration diagram example
4 146 Chapter 10 Analysis Modeling The labels associated with each of the actors and classes comprising a collaboration diagram use the object : class notation, in which the class name appears after a colon. In the preceding figure, the single boundary class is labeled Check Out UI. This notation indicates that this class is of type Check Out UI. If you intend to specify an instance of a class, you can use the object field to specify the name of the instance. For example, if the activity depicted in the preceding figure could only be initiated by a librarian named Mark, you could specify Mark by labeling the actor Mark : Librarian. Notice that at this stage you need not be concerned with creating class names that conform to program syntax or coding standards. Check Out UI is not a valid class name. The Check Out UI boundary class actually represents a collection of classes representing windows, scroll bars, and all the elements that form the user interface. For now, you are developing an overview of the system, and details can be addressed later. The line between the Librarian actor and the Check Out UI boundary class associates the two. It provides a pathway for communication, which is in the form of messages. In this case, a single message is passed from the Librarian to the boundary class. An arrow illustrates the direction of this message. Sequence numbers and parameter passing Figure 10-2 expands on the preceding collaboration diagram. Notice that a control class, Check Out Controller, has been added to the system. The control class is the center of the Check Out Asset use case. It will act as a dispatcher, transmitting messages to other classes that will perform the work of checking out an asset. The Check Out UI class sends a message to the Check Out Controller class. Notice that both messages are labeled with a sequence number. This numbering indicates the order in which messages are passed. The first message is sent from the librarian to the Check Out UI class, which responds by dispatching a message to the Check Out Controller class. 1: Select patron(patronid) 2: Select patron(patronid) : Librarian : Check Out UI : Check Out Controller Figure 10-2: Sequence numbers and parameter passing
5 Collaboration Diagrams 147 The message to the Check Out Controller class is to select a patron. In order to perform this action, the Check Out Controller class will need information about the patron being selected. The patron's identification number (which is scanned or entered from the library card) is passed as an argument to the Check Out Controller class. This notation is intentionally formatted to the syntax of most programming languages. In most cases, the messages sent between classes take the form of method calls. Return values Figure 10-3 expands on the preceding collaboration diagram. A third class, Patron Account, has been added and is an entity class. A third message, Get Account Balance, has been added between the Check Out Controller class and the Patron Account class. This message takes no arguments because, in the final system, this message will be sent to a specific instance of the Patron Account class. As noted previously, the Get Account Balance can be thought of as a message call. The diagram can capture the return value for use by the calling object. In this case, the return value is stored in a variable balance. 1: Select patron(patronid) 2: Select patron(patronid) : Librarian :CheckOutUI : Check Out Controller 3: balance := Get Account Balance : Patron Account Figure 10-3: Return value example
6 148 Chapter 10 Analysis Modeling Message conditions Figure 10-4 adds a second control class, the Pay Overdue Fine class. If the patron owes an overdue fine, that fine must be paid before any library assets can be checked out. Thus a condition is placed on message 4. The condition indicated by brackets indicates that the Pay Overdue Fine message will only be sent if the account balance is greater than zero, or balance > 0. 1: Select patron(patronid) 2: Select patron(patronid) 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 3: balance := Get Account Balance : Patron Account Figure 10-4: Message condition example
7 Collaboration Diagrams 149 Multiplicity Once a patron has been selected and any outstanding overdue fines have been paid, the librarian enters a cycle of adding assets to the list of assets to be checked out. This cycle continues until all the assets being checked out have been added to the list. Figure 10-5 adds the Asset List class and the messages required to add assets to the list. The asterisk next to message 5 indicates multiplicity; this message may be executed multiple times as assets continue to be added. 1: Select patron(patronid) 2: Select patron(patronid) 5*: Add asset(assetid) 6: Add asset(assetid) 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 7: Add asset(assetid) 3: balance := Get Account Balance :AssetList : Patron Account Figure 10-5: Multiplicity example
8 150 Chapter 10 Analysis Modeling Figure 10-6 is the complete collaboration diagram for the Check Out Asset use case. 1: Select patron(patronid) 2: Select patron(patronid) 5*: Add asset(assetid) 6: Add asset(assetid) 8: Complete transaction 9: Complete transaction 4: [balance > 0] Pay overdue fine : Librarian :CheckOutUI :CheckOut Controller : Pay Overdue Fine Controller 7: Add asset(assetid) 11: Mark assets as checked out 3: balance := Get Account Balance 10: Add assets to account :AssetList : Patron Account 12: Mark assets as checked out : Asset Database Figure 10-6: Check Out Asset collaboration diagram The collaboration diagrams created within the analysis workflow provide a rough overview of how each use case will be implemented. Using an expanded notation, collaboration diagrams can provide a more complete view of system design. Collaboration diagrams during the design phase will be revisited.
9 Flow of Events and Special Requirements 151 FLOW OF EVENTS AND SPECIAL REQUIREMENTS Collaboration diagrams efficiently express the relationship between the classes in a use case. However, it is difficult to fully comprehend the sequence of events. Collaboration diagrams employ sequence numbering to assist in deciphering the order of events, but tracing the path of messages can be time consuming. Analysts can employ two methods to better communicate the sequence of message passing within a collaboration diagram. One method is to create a second type of interaction diagram called a sequence diagram. It contains all the same information contained in a collaboration diagram, yet in a form that places greater emphasis on the sequence of events than on specific object relationships. Creating sequence diagrams will be discussed in a later chapter. A second method is to supplement the collaboration diagram with a textual description of the sequence of events called a flow-of-events description. The following is an example of a flow-of-events description for the Check Out Asset collaboration diagram: A librarian uses a bar code scanner or the keyboard to input a patron identification number (1). The user interface dispatches the patron identification number to the Check Out Controller (2). The Check Out Controller queries the Patron Account for the patron's account balance (3). If the balance > 0, control is transferred to the Pay Overdue Fine Controller (4). Once the patron's account balance is resolved, the librarian may begin entering asset identification numbers, using a bar code scanner or the keyboard. The asset identification number is dispatched from the Check Out UI to the Check Out Controller, which adds the asset to a list of assets being checked out. This process continues until all assets being checked out have been added to the list (5, 6, 7). When the librarian has completed the process of entering assets, he indicates to the Check Out UI that he wants to complete the transaction (8). This message is relayed to the Check Out Controller (9). The Check Out Controller adds the assets to the patron's account information and marks the assets as checked out (10, 11, 12). In addition to the flow-of-events description, each collaboration diagram may also be accompanied by a special-requirements description. The special-requirements description is a brief list of any non-functional requirements that should be considered.
10 152 Chapter 10 Analysis Modeling CLASS-RESPONSIBILITY-COLLABORATION CARDS Creating collaboration diagrams can be difficult, and the first design is rarely the final design. Class-Responsibility-Collaboration (CRC) cards are a tool used to simplify the analysis and design process. Analysts use index cards to represent each prospective class. Each card is labeled with the name of the class. A group of analysts and designers meet to discuss how the classes might interact, and a list of fundamental responsibilities is created for each class. These responsibilities are listed on the card. Next to each responsibility is the name of a second class with which the class must collaborate to fulfill the responsibility. Figure 10-7 illustrates a sample CRC card for the Check Out Controller class. Responsibilities are listed in the left column, and the collaborating classes are listed in the right column. Check Out Controller Allow user to pay overdue fine Check patron's account balance Add assets to patron's account Add assets to the list of assets being checked out Mark assets as checked out Pay Overdue Fine Controller Patron Account Asset List Figure 10-7: Example CRC card Rather than continually redrawing collaboration diagrams, CRC cards can be shuffled around a table as new scenarios are discussed. When analysts come to a consensus for a particular use-case realization analysis, they can begin translating the CRC cards into a collaboration diagram. The resulting diagrams are then re-evaluated, perhaps several times, until the team is satisfied with the design of the class interaction.
11 Class Analysis 153 CLASS ANALYSIS After completing collaboration diagrams, analysts take a closer look at individual analysis classes. CRC cards and collaboration diagrams provide information about the classes in a use-case realization analysis, their responsibilities, and the classes with which they collaborate. During class analysis, each class is analyzed more closely to identify class attributes, aggregations, and generalizations. Attributes Class attributes are properties of a class. In Chapter 2, class member variables were introduced. Think about member variables in terms of their data types. Within the analysis workflow, analysis classes are assigned properties. Unlike programmers, analysts are not concerned with specifics of implementation such as data type. Analysis class attributes can be defined in more general terms. For example, a book has an ISBN; the specifics of whether the ISBN will be stored as a string or as a set of integers can be addressed in design. Aggregation and generalization One type of analysis relationship, the association, has already been introduced. Collaboration diagrams depict associations between analysis classes. In Chapter 2, you were introduced to the "uses a" relationship. Associations are "uses a" relationships; the Check Out Controller uses a Patron Account. Two other relationships, the "has a" relationship and the "is a" relationship, were also introduced. These relationships translate to aggregation and generalization, which should be identified between classes as within the analysis workflow. Aggregation is the "has a" relationship. A patron's account information includes a list of assets currently checked out. Within the system, a patron's account and the list of assets are both represented by classes. The patron's account "has an" asset list. This relationship is called an aggregation because an asset list is part of a patron's account. In many ways, this relationship is identical to attributes.
12 154 Chapter 10 Analysis Modeling Generalization is the "is a" relationship. You will recall from Chapter 3 that the "is a" relationship denotes inheritance. A book "is a" lendable asset. In that way, a book inherits all the attributes and functionality of a lendable asset. WHEN IS THIS USEFUL Many ways of describing processes include collaboration, sequence, and activity diagrams. However, collaboration diagrams are most useful when providing information on the specific relationships between all the classes that will be used throughout a process. As shown above, relationships can be either very simple or extremely complex. A few disadvantages of the way collaboration diagrams work include a lack of a clear sequence of the process, or description of what happens when operations occur in parallel. Thus, collaboration diagrams should be used only when a description of the classes interacting is needed. When combined with the use of CRC cards, collaboration diagrams provide a easy and efficient way to test class interactions as well as providing a clear view of who will be involved with a process and how they will be involved.
13 Summary 155 Exercise 10-1: Creating analysis models In this exercise, you will conduct analysis modeling. Follow all the steps for each use case you identified for the grocery store inventory system. SUMMARY 1. Identify high-level classes and create CRC cards for each class. 2. Using the CRC cards you created in Step 1, consider how the various classes might interact. Determine responsibilities and collaborations for each class and write them on the CRC cards. 3. Create a collaboration diagram to depict the relationships between classes. 4. Create a flow-of-events description. 5. If any special requirements exist, consider creating a special-requirements description. 6. Identify attributes of the analysis classes you identified in Step Identify associations, aggregations, and generalizations of the analysis classes you identified in Step 1. Collaboration diagrams are a form of interaction diagram used to describe the interaction between classes in a use-case realization analysis. A second type of interaction diagram, called a sequence diagram, conveys the same information as a collaboration diagram, with an emphasis on the sequence of events. A flow-of-events description can accompany a collaboration diagram to better communicate the sequence of message passing. A specialrequirements description listing any nonfunctional requirements may also accompany a collaboration diagram. CRC cards are a tool used to simplify the analysis and design process.
14 156 Chapter 10 Analysis Modeling POST-TEST QUESTIONS The answers to these questions are in Appendix A at the end of this manual. 1. How are CRC cards used in analysis modeling? 2. What is the purpose of a flow-of-events description?
Chapter 5: Structural Modeling
Chapter 5: Structural Modeling Objectives Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. Understand the processes used to create CRC cards, class
More informationUnderstanding the Object Paradigm
2 Understanding the Object Paradigm M MAJOR A J O R T TOPICSO P I C S Objectives... 18 Pre-Test Questions... 18 Introduction... 19 Classes... 19 Classes and Functions... 20 Abstraction... 25 Adding and
More informationSOFTWARE ENGINEERING UML FUNDAMENTALS. Saulius Ragaišis.
SOFTWARE ENGINEERING UML FUNDAMENTALS Saulius Ragaišis saulius.ragaisis@mif.vu.lt Information source Slides are prepared on the basis of Bernd Oestereich, Developing Software with UML: Object- Oriented
More informationRequirements Engineering
Chapter 3: Requirements Modeling Requirements Engineering Objectives In this chapter, you will learn about: Functional requirements Modeling requirements Overview of basic modeling paradigms Gus Requirements
More information06. Analysis Modeling
06. Analysis Modeling Division of Computer Science, College of Computing Hanyang University ERICA Campus 1 st Semester 2017 Overview of Analysis Modeling 1 Requirement Analysis 2 Analysis Modeling Approaches
More informationProgress Report. Object-Oriented Software Development: Requirements elicitation (ch. 4) and analysis (ch. 5) Object-oriented software development
Progress Report Object-Oriented Software Development: Requirements elicitation (ch. 4) and analysis (ch. 5) CS 4354 Summer II 2014 Jill Seaman So far we have learned about the tools used in object-oriented
More informationObject-Oriented Systems Analysis and Design Using UML
10 Object-Oriented Systems Analysis and Design Using UML Systems Analysis and Design, 8e Kendall & Kendall Copyright 2011 Pearson Education, Inc. Publishing as Prentice Hall Learning Objectives Understand
More informationUse Case Model. Static Structure. Diagram. Collaboration. Collaboration. Diagram. Collaboration. Diagram. Diagram. Activity. Diagram.
!"# $%&' !" #" $%%&&& ! Static Structure Diagram Collaboration Collaboration Diagram Collaboration Diagram Diagram Activity Diagram CRC Card CRC Card UML defines a standard notation for object-oriented
More informationITEC420: Software Engineering Lecture 3: Recap OO/UML Requirement Workflow
ITEC420: Software Engineering Lecture 3: Recap OO/UML Requirement Workflow Box Leangsuksun SWECO Endowed Professor, Computer Science Louisiana Tech University box@latech.edu CTO, PB Tech International
More informationTopics. Overview- The UML Functional Model. Structural Model. Behavioral Models. Use Case Diagram (essential and system)
Topics Overview- The UML Functional Model Use Case Diagram (essential and system) Structural Model Class/object, Component and Deployment Diagram Behavioral Models Activity, State chart, sequence /collaboration
More informationObject-Oriented Analysis and Design Using UML (OO-226)
Object-Oriented Analysis and Design Using UML (OO-226) The Object-Oriented Analysis and Design Using UML course effectively combines instruction on the software development processes, objectoriented technologies,
More informationUnified Modeling Language
Unified Modeling Language Modeling Applications using Language Mappings Programmer s Reference Manual How to use this Reference Card: The consists of a set of fundamental modeling elements which appear
More informationCOSC 3351 Software Design. An Introduction to UML (I)
COSC 3351 Software Design An Introduction to UML (I) This lecture contains material from: http://wps.prenhall.com/esm_pfleeger_softengtp_2 http://sunset.usc.edu/classes/cs577a_2000/lectures/05/ec-05.ppt
More informationBPMN Working Draft. 1. Introduction
1. Introduction The Business Process Management Initiative (BPMI) has developed a standard Business Process Modeling Notation (BPMN). The primary goal of BPMN is to provide a notation that is readily understandable
More informationThe ATCP Modeling Framework
The ATCP 2+9+1 Modeling Framework Bobbi Underbakke Adaptive Team Collaboration, Inc. 800.837.0677 atcprocess.com Adaptive Team Collaboration, Inc. March 22, 2005 Chris Armstrong Armstrong Process Group,
More informationIntroduction to UML p. 1 Introduction to the Object-Oriented Paradigm p. 1 What Is Visual Modeling? p. 6 Systems of Graphical Notation p.
Introduction p. xxi Introduction to UML p. 1 Introduction to the Object-Oriented Paradigm p. 1 What Is Visual Modeling? p. 6 Systems of Graphical Notation p. 7 Understanding UML Diagrams p. 10 Visual Modeling
More informationLab Manual For Software Engineering
DATTA MEGHE COLLEGE OF ENGINEERING Department of Information Technology Lab Manual For Software Engineering Semester Jan 2016-April 2016 Page 1 CONTENTS Page No. 1. Objectives SE Lab 4 2. Leaning on the
More informationUnit Wise Questions. Unit-1 Concepts
Unit Wise Questions Unit-1 Concepts Q1. What is UML? Ans. Unified Modelling Language. It is a Industry standard graphical language for modelling and hence visualizing a blue print of all the aspects of
More informationChapter 4. Capturing the Requirements. 4th Edition. Shari L. Pfleeger Joanne M. Atlee
Chapter 4 Capturing the Requirements Shari L. Pfleeger Joanne M. Atlee 4th Edition It is important to have standard notations for modeling, documenting, and communicating decisions Modeling helps us to
More informationÄriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel
Äriprotsesside modelleerimine ja automatiseerimine Loeng 7 Valdkonna mudel Enn Õunapuu enn.ounapuu@ttu.ee What is a domain model? A domain model captures the most important types of objects in the context
More informationUNIVERSITY OF CAMBRIDGE INTERNATIONAL EXAMINATIONS International General Certificate of Secondary Education
UNIVERSITY OF CAMBRIDGE INTERNATIONAL EXAMINATIONS International General Certificate of Secondary Education INFORMATION TECHNOLOGY Paper 2 Candidates answer on the Question Paper. No Additional Materials
More informationSoftware Life-Cycle Models
Software Life-Cycle Models CMPSC 487 Lecture 03 Topics: UML Class Diagram Rosenburg Chap 2. Domain Modeling A. UML: Unified Modeling Language UML is a general-purpose, developmental, modeling language
More informationAPPENDIX M INTRODUCTION TO THE UML
M INTRODUCTION TO THE UML This appendix, written only for those readers not familiar with the topic, provides a brief introduction, which cannot be considered as exhaustive, to the UML. The UML is a general-purpose
More informationChapter 2: The Object-Oriented Design Process
Chapter 2: The Object-Oriented Design Process In this chapter, we will learn the development of software based on object-oriented design methodology. Chapter Topics From Problem to Code The Object and
More informationPractical UML - A Hands-On Introduction for Developers
Practical UML - A Hands-On Introduction for Developers By: Randy Miller (http://gp.codegear.com/authors/edit/661.aspx) Abstract: This tutorial provides a quick introduction to the Unified Modeling Language
More informationOBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization
OBJECT ORIENTED DESIGN with the Unified Process Use Case Realization 2016 Software Engineering 2 (Zoom-Into Design) Requirement Requirement Specification (Functional & Non- Functional) analysis Requirement
More informationEnterprise Architect. User Guide Series. Testpoints. Author: Sparx Systems. Date: 30/06/2017. Version: 1.0 CREATED WITH
Enterprise Architect User Guide Series Testpoints Author: Sparx Systems Date: 30/06/2017 Version: 1.0 CREATED WITH Table of Contents Testpoints 3 Test Domain Diagram 7 Test Cut 9 Test Set 10 Test Suite
More informationCHAPTER 1. Topic: UML Overview. CHAPTER 1: Topic 1. Topic: UML Overview
CHAPTER 1 Topic: UML Overview After studying this Chapter, students should be able to: Describe the goals of UML. Analyze the History of UML. Evaluate the use of UML in an area of interest. CHAPTER 1:
More informationObject Oriented Software Development CIS Today: Object Oriented Analysis
Object Oriented Software Development CIS 50-3 Marc Conrad D104 (Park Square Building) Marc.Conrad@luton.ac.uk Today: Object Oriented Analysis The most single important ability in object oriented analysis
More informationEnhancing validation with Prototypes out of Requirements Model
Enhancing validation with Prototypes out of Requirements Model Michael Deynet, Sabine Niebuhr, Björn Schindler Software Systems Engineering, Clausthal University of Technology, 38678 Clausthal-Zellerfeld,
More informationArchitectural Blueprint
IMPORTANT NOTICE TO STUDENTS These slides are NOT to be used as a replacement for student notes. These slides are sometimes vague and incomplete on purpose to spark a class discussion Architectural Blueprint
More informationChapter 10 Object-Oriented Design Principles
Chapter 10 Object-Oriented Design Principles Dr. Supakit Nootyaskool Faculty of Information Technology King Mongkut s Institute of Technology Ladkrabang Outline Object-oriented design: bridging from analysis
More informationBPMN Working Draft. 1. Introduction
1. Introduction The Business Process Management Initiative (BPMI) has developed a standard Business Process Modeling Notation (BPMN). The primary goal of BPMN is to provide a notation that is readily understandable
More informationThe Open Group SOA Ontology Technical Standard. Clive Hatton
The Open Group SOA Ontology Technical Standard Clive Hatton The Open Group Releases SOA Ontology Standard To Increase SOA Adoption and Success Rates Ontology Fosters Common Understanding of SOA Concepts
More informationModeling with UML. (1) Use Case Diagram. (2) Class Diagram. (3) Interaction Diagram. (4) State Diagram
Modeling with UML A language or notation intended for analyzing, describing and documenting all aspects of the object-oriented software system. UML uses graphical notations to express the design of software
More informationHippo Software BPMN and UML Training
Hippo Software BPMN and UML Training Icon Key: www.hippo-software.co.uk Teaches theory concepts and notation Teaches practical use of Enterprise Architect Covers BPMN, UML, SysML, ArchiMate Includes paper
More informationQuestion Sheet There are a number of criticisms to UML. List a number of these criticisms.
Question Sheet 1 Name: ID: These questions do not have a formal, definitive answer. They are meant to be food for thoughts. Feel free to seek answers on browsing the Internet, talking to other software
More informationUnified Modeling Language (UML)
Unified Modeling Language (UML) Troy Mockenhaupt Chi-Hang ( Alex) Lin Pejman ( PJ ) Yedidsion Overview Definition History Behavior Diagrams Interaction Diagrams Structural Diagrams Tools Effect on Software
More informationArchitectural Design. Architectural Design. Software Architecture. Architectural Models
Architectural Design Architectural Design Chapter 6 Architectural Design: -the design the desig process for identifying: - the subsystems making up a system and - the relationships between the subsystems
More informationRequirements Analysis. SE 555 Software Requirements & Specification
Requirements Analysis Goals of Requirements Analysis Create requirements containing sufficient detail and of high enough quality to allow realistic project planning as well as successful design and implementation.
More informationSoftware Engineering Fall 2014
Software Engineering Fall 2014 (CSC 4350/6350) Mon.- Wed. 5:30 pm 7:15 pm ALC : 107 Rao Casturi 10/01/2014 Class Announcements Grading is done for the Deliverable #2 (Requirement Elicitation) Will be posed
More informationICIS PROJECT #2 CONNECTING SPECIFICATIONS AND BIM SUB-PROJECT #2
ICIS PROJECT #2 CONNECTING SPECIFICATIONS AND BIM SUB-PROJECT #2 ISSUE VERSION: V1.1 DATE: January 2014 PROJECT TEAM: Leader: Richard Choy (NATSPEC) Task Team: Rolf Huber (CIL) Sato Takayoshi (IIBH) Technical
More informationCSE 403. UML Sequence Diagrams. Reading: UML Distilled Ch. 4, by M. Fowler
CSE 403 UML Sequence Diagrams Reading: UML Distilled Ch. 4, by M. Fowler These lecture slides are copyright (C) Marty Stepp, 2007. They may not be rehosted, sold, or modified without expressed permission
More informationFUNCTIONAL MODELLING
FUNCTIONAL MODELLING http://www.tutorialspoint.com/object_oriented_analysis_design/ooad_functional_modeling.htm Copyright tutorialspoint.com Functional Modelling gives the process perspective of the object-oriented
More informationCS211 Lecture: Modeling Dynamic Behaviors of Systems; Interaction Diagrams in UML
CS211 Lecture: Modeling Dynamic Behaviors of Systems; Interaction Diagrams in UML Objectives: 1. To introduce the notion of dynamic analysis 2. To show how to create and read Sequence Diagrams 3. To show
More informationToday s Agenda UML. CompSci 280 S Introduction to Software Development. 1.Introduction UML Diagrams. Topics: Reading:
CompSci 280 S2 2107 Introduction to Software Development Today s Agenda Topics: Introduction Activity Diagram Object interaction Sequence Diagram Reading: Booch G.,The Unified Modeling Language User Guide,
More informationPractical UML : A Hands-On Introduction for Developers
Borland.com Borland Developer Network Borland Support Center Borland University Worldwide Sites Login My Account Help Search Practical UML : A Hands-On Introduction for Developers - by Randy Miller Rating:
More informationObjectives. Explain the purpose and objectives of objectoriented. Develop design class diagrams
Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop interaction diagrams based on the principles of object responsibility and use case controllers
More informationLab Manual. Object Oriented Analysis And Design. TE(Computer) VI semester
Lab Manual Object Oriented Analysis And Design TE(Computer) VI semester Index Sr. No. Title of Programming Assignment Page No. 1 2 3 4 5 6 7 8 9 10 Study of Use Case Diagram Study of Activity Diagram Study
More informationSoftware Development Methodologies
Software Development Methodologies Lecturer: Raman Ramsin Lecture 3 Seminal Object-Oriented Methodologies: A Feature-Focused Review 1 Responsibility-Driven Design (RDD) Introduced in 1990; a UML-based
More informationIntroduction. Chapter 1. What Is Visual Modeling? The Triangle for Success. The Role of Notation. History of the UML. The Role of Process
Quatrani_Ch.01.fm Page 1 Friday, October 27, 2000 9:02 AM Chapter 1 Introduction What Is Visual Modeling? The Triangle for Success The Role of Notation History of the UML The Role of Process What Is Iterative
More informationDarshan Institute of Engineering & Technology for Diploma Studies
REQUIREMENTS GATHERING AND ANALYSIS The analyst starts requirement gathering activity by collecting all information that could be useful to develop system. In practice it is very difficult to gather all
More informationA - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models
CS 494 Object-Oriented Analysis & Design UML Class Models Overview How class models are used? Perspectives Classes: attributes and operations Associations Multiplicity Generalization and Inheritance Aggregation
More informationRequirements Elicitation
Requirements Elicitation Introduction into Software Engineering Lecture 4 25. April 2007 Bernd Bruegge Applied Software Engineering Technische Universitaet Muenchen 1 Outline Motivation: Software Lifecycle
More informationChapter : Analysis Modeling
Chapter : Analysis Modeling Requirements Analysis Requirements analysis Specifies software s operational characteristics Indicates software's interface with other system elements Establishes constraints
More informationOBJECT ORIENTED DESIGN with the Unified Process. Use Case Realization
OBJECT ORIENTED DESIGN with the Unified Process Use Case Realization Objectives Explain the purpose and objectives of objectoriented design Develop design class diagrams Develop detailed sequence diagrams
More informationUML Fundamental. OutLine. NetFusion Tech. Co., Ltd. Jack Lee. Use-case diagram Class diagram Sequence diagram
UML Fundamental NetFusion Tech. Co., Ltd. Jack Lee 2008/4/7 1 Use-case diagram Class diagram Sequence diagram OutLine Communication diagram State machine Activity diagram 2 1 What is UML? Unified Modeling
More informationUML Is Not a Methodology
UML COSC 4354 1 UML Is Not a Methodology UML is an acronym for Unified Modeling Language UML is a language A language is simply a tool for communication and exchanging ideas UML is a notation, not a methodology
More informationFollow this and additional works at: Part of the Information Literacy Commons
Wright State University CORE Scholar University Libraries' Staff Publications University Libraries 10-7-2016 Circulation Rules Leigh Ann Duncan Wright State University - Main Campus, leigh.duncan@wright.edu
More information1 OBJECT-ORIENTED ANALYSIS
UML and Patterns.book Page 3 Sunday, August 9, 200 2:50 PM Chapter OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs.
More informationuser.book Page 45 Friday, April 8, :05 AM Part 2 BASIC STRUCTURAL MODELING
user.book Page 45 Friday, April 8, 2005 10:05 AM Part 2 BASIC STRUCTURAL MODELING user.book Page 46 Friday, April 8, 2005 10:05 AM user.book Page 47 Friday, April 8, 2005 10:05 AM Chapter 4 CLASSES In
More informationProgress Report. Object-Oriented Software Development: Requirements elicitation and analysis. Object-oriented analysis, design, implementation
Progress Report Object-Oriented Software Development: Requirements elicitation and analysis CS 4354 Fall 2012 Jill Seaman So far we have learned about the tools used in object-oriented design and implementation
More informationSoftware Development Chapter 1
Software Development Chapter 1 1. Introduction Software Applications are increasingly used to tackle problems that concern everyday life : Automatic Bank tellers Airline reservation systems Air traffic
More informationAns 1-j)True, these diagrams show a set of classes, interfaces and collaborations and their relationships.
Q 1) Attempt all the following questions: (a) Define the term cohesion in the context of object oriented design of systems? (b) Do you need to develop all the views of the system? Justify your answer?
More informationSuggested answers are provided below. These answers are presented top-down, left to right.
Answers to Key Terms Suggested answers are provided below. These answers are presented top-down, left to right. 5. Actor 16. Concrete class 39. Use case 13. Class-scope attribute 40. Use-case diagram 2.
More informationSoftware Engineering I (02161)
Software Engineering I (02161) Week 2: Class diagrams part 1 Hubert Baumeister Informatics and Mathematical Modelling Technical University of Denmark Spring 2010 c 2010 H. Baumeister (IMM) Software Engineering
More informationMandarin Oasis TM Library Automation System
Mandarin Oasis TM Library Automation System Daily Use Handbook This handbook explains routine library tasks using Mandarin Oasis. It is designed to supplement Oasis training by providing simple, step-by-step
More informationADELFE FRAGMENTATION
ADELFE FRAGMENTATION Tom Jorquera Christine Maurel Frédéric Migeon Marie-Pierre Gleizes Carole Bernon Noélie Bonjean IRIT Université Paul Sabatier 118, route de Narbonne 31 062 Toulouse Cedex 9 Rapport
More informationOO System Models Static Views
OO System Models Static Views UML Class & Object Diagrams Software Engineering OO Models Class Diagram Slide 1 Objective Introduces the evolutionary approach for building classes Explain how to identify
More informationTopics. Kinds of UML models. Use case modeling. Actors. Actor. Assignment of reqs to actors and use cases
MACIASZEK, L.A. (2005): Requirements Analysis and System Design, 2 nd ed. Addison Wesley, Harlow England, 504p. ISBN 0 32 20464 6 Chapter 3.2 Objects and Object Modeling Fundamentals of object modeling
More informationAppendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
More informationObject-Oriented Software Engineering Practical Software Development using UML and Java
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 5: Modelling with Classes Lecture 5 5.1 What is UML? The Unified Modelling Language is a standard graphical
More informationEditors. Getting Started
Editors The Editor oversees entire editorial and publishing process. The Editor, working with the Journal Manager, typically establishes the policies and procedures for the journal, which are used in setting
More informationStructured and Object Oriented Analysis and Design
RAMRAO ADIK INSTITUTE OF TECHNOLOGY, NERUL Department of Computer Engineering Lab Manual Structured and Object Oriented Analysis and Design 2015-2016 List of Experiments Subject: Structured and object
More informationBusiness Modelling. PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e. Early phase of development Inputs: Activities: informal specification
PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 4: Restaurant System: Business Modelling Slide 1/1 Business Modelling Early phase of development Inputs: informal specification Activities: create use
More informationSoftware Design Models, Tools & Processes. Lecture 2: Inception Phase Cecilia Mascolo
Software Design Models, Tools & Processes Lecture 2: Inception Phase Cecilia Mascolo Inception Phase This is the phase when most of the system requirements are identified. Discover and reach agreement
More informationLecture 4: Design Concepts For Responsibility- Driven Design Kenneth M. Anderson January 20, 2005
Lecture 4: Design Concepts For Responsibility- Driven Design Kenneth M. Anderson 1 of 25 Introduction Chapter 1 of Object Design covers topics that aid understanding of Responsibility-Driven Design Object
More informationCS 1044 Program 6 Summer I dimension ??????
Managing a simple array: Validating Array Indices Most interesting programs deal with considerable amounts of data, and must store much, or all, of that data on one time. The simplest effective means for
More informationObject-Oriented Design
Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1 UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration
More informationChapter. Relational Database Concepts COPYRIGHTED MATERIAL
Chapter Relational Database Concepts 1 COPYRIGHTED MATERIAL Every organization has data that needs to be collected, managed, and analyzed. A relational database fulfills these needs. Along with the powerful
More informationMilestone 1.1 Ethan Kang and Peter Crossman. 2. Sequence of Events. Requirement 1: Clerk / manager Check out more copies to patron
Milestone 1.1 Ethan Kang and Peter Crossman 2. Sequence of Events Requirement 1: a. Check out Copies Clerk / manager Check out more copies to patron When a patron asks the clerk to check out one or more
More informationBusiness Process Modelling
CS565 - Business Process & Workflow Management Systems Business Process Modelling CS 565 - Lecture 2 20/2/17 1 Business Process Lifecycle Enactment: Operation Monitoring Maintenance Evaluation: Process
More informationAlma. Resource Sharing - Borrowing. Limor Cohen Head of Circulation and Interlibrary Loan Department. Technion Israel Institute of Technology
Alma Resource Sharing - Borrowing Limor Cohen Head of Circulation and Interlibrary Loan Department Israel Institute of Technology Table of Content Borrowing Request Books via on-line form Books via email
More informationOral Questions. Unit-1 Concepts. Oral Question/Assignment/Gate Question with Answer
Unit-1 Concepts Oral Question/Assignment/Gate Question with Answer The Meta-Object Facility (MOF) is an Object Management Group (OMG) standard for model-driven engineering Object Management Group (OMG)
More informationArchiMate Trick or Treat?
July ArchiMate 3.0 - Trick or Treat? Bruno Vandenborre EA Forum Contents Introduction Why ArchiMate 3.0? What is new, has changed, or improved? Conclusion Page 2 Introduction What is ArchiMate? A language
More informationClass diagrams. Modeling with UML Chapter 2, part 2. Class Diagrams: details. Class diagram for a simple watch
Class diagrams Modeling with UML Chapter 2, part 2 CS 4354 Summer II 2015 Jill Seaman Used to describe the internal structure of the system. Also used to describe the application domain. They describe
More informationPertemuan 8. Object Oriented Modeling and Design
Pertemuan 8 Object Oriented Modeling and Design References Rumbaugh, James et al., Object Oriented Modeling and Design, 1991, Prentice Hall, Inc., USA, ISBN: 0 13 629841 9 9 Coad, Peter and Yourdon, Edward,
More informationIndex. : (colon), 80 <<>> (guillemets), 34, 56
: (colon), 80 (guillemets), 34, 56 A Abstraction, 3 Acronyms, 54 Action field, 140 Actions tab, 140 ActiveX controls (Microsoft), 163 Activities. See also Activity diagrams basic description of, 241
More information- Evergreen Reports Training Session - Handouts. September 29, 2016 Hermiston Public Library
- Evergreen Reports Training Session - Handouts September 29, 2016 Hermiston Public Library - Handout 00 - Commonly Used Report Information Needs We use reports to answer a multitude of questions regarding
More informationUNIT-II Introduction to UML
UNIT-II Introduction to UML - P. P. Mahale UML OVERVIEW OF UML :- We need a Modeling Language! We will use the Unified Modeling Language, UML), Provides a standard for artifacts produced during development
More informationSoftware Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm. Rao Casturi 09/29/2015
Software Engineering Fall 2015 (CSC 4350/6350) TR. 5:30 pm 7:15 pm Rao Casturi 09/29/2015 http://cs.gsu.edu/~ncasturi1 Class Announcements Grading is done for the Deliverable #2 (Requirement Elicitation)
More informationUML- a Brief Look UML and the Process
UML- a Brief Look UML grew out of great variety of ways Design and develop object-oriented models and designs By mid 1990s Number of credible approaches reduced to three Work further developed and refined
More informationAn Integrated Approach to Documenting Requirements with the Rational Tool Suite
Copyright Rational Software 2002 http://www.therationaledge.com/content/dec_02/t_documentreqs_kd.jsp An Integrated Approach to Documenting Requirements with the Rational Tool Suite by Kirsten Denney Advisor
More informationUse-Case Analysis. Architecture Oriented Analysis. R. Kuehl/J. Scott Hawker p. 1 R I T. Software Engineering
Use-Case Analysis Architecture Oriented Analysis R. Kuehl/J. Scott Hawker p. 1 Notes The slides are based on UML use-case analysis techniques This is an introduction detailed techniques and notation will
More informationMay Comp-B 11, Advanced Software Design. 3 hours duration
May 2016 98-Comp-B 11, Advanced Software Design 3 hours duration NOTES: 1. If doubt exists as to the interpretation of any question, the candidate is urged to submit, with the answer paper, a clear statement
More informationC/W MARS Evergreen Circulation
C/W MARS Evergreen Circulation This document is an introduction to using Evergreen Circulation to check items in and out, to renew items, to pay fines, and to place and search item holds. It also includes
More informationMeltem Özturan
Meltem Özturan www.mis.boun.edu.tr/ozturan/samd 1 2 Modeling System Requirements Object Oriented Approach to Requirements OOA considers an IS as a set of objects that work together to carry out the function.
More informationSOFTWARE MODELING AND DESIGN. UML, Use Cases, Patterns, and. Software Architectures. Ki Cambridge UNIVERSITY PRESS. Hassan Gomaa
SOFTWARE MODELING AND DESIGN UML, Use Cases, Patterns, and Software Architectures Hassan Gomaa George Mason University, Fairfax, Virginia Ki Cambridge UNIVERSITY PRESS Contents Preface P"U
More informationBPS Suite and the OCEG Capability Model. Mapping the OCEG Capability Model to the BPS Suite s product capability.
BPS Suite and the OCEG Capability Model Mapping the OCEG Capability Model to the BPS Suite s product capability. BPS Contents Introduction... 2 GRC activities... 2 BPS and the Capability Model for GRC...
More informationObject-Oriented Systems Development: Using the Unified Modeling Language
Object-Oriented Systems Development: Using the Unified Modeling Language Chapter 5: Unified Modeling Language Goals Modeling. Unified modeling language. Class diagram. Use case diagram. Interaction diagrams.
More information