system architect - sharif university of...

System Architect

Tutorial

Popkin Software Part Number 2001-3 Printed in the U.S.A.

Popkin Software makes no representations or warranties with respect to the contents hereof and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Further, Popkin Software reserves the right to revise this publication and to make changes from time to time in the content hereof without obligation of Popkin Software to notify any person or organization of such revision or changes.

The software described in this document is furnished under a license agreement. The software may be used or copied only in accordance with the terms of the agreement. No part of this manual may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose other than the purchaser’s personal use without the written permission of Popkin Software. You may use the .PDF files supplied with the software to print a maximum of four copies of this manual. If you need more than four copies, please contact Popkin.

The System Architect logo is a trademark of Popkin Software.

Publication No. 8.1244

Copyright 2001 Popkin Software & Systems, Inc. All rights reserved.

Table of Contents

I

Table of Contents Table of Contents........................................................................................................I Introduction .............................................................................................................1-1

The Project: An International Hotel Business...............................................1-2 The Zachman Framework ............................................................................1-3 The Popkin Enterprise Framework...............................................................1-5 Process Chart for Tutorial ............................................................................1-6

Getting Started ........................................................................................................2-1 Starting System Architect .............................................................................2-2 Creating/Opening an Encyclopedia ..............................................................2-3 Set Preferences............................................................................................2-6 An Explanation of Some Preferences ..........................................................2-7

Creating a Business Profile....................................................................................3-1 Defining a Business Profile ..........................................................................3-2 Review the Business Profile Definition.........................................................3-4 The Business Segment Profile.....................................................................3-6

Adding a New Business Segment .....................................................3-8 Reviewing the Products and Customers ......................................................3-9 Customers Profile.......................................................................................3-11 Reviewing Suppliers and Competitors .......................................................3-13 Business Forces Summary ........................................................................3-15

Establish the Business Enterprise Direction........................................................4-1 Business Enterprise Direction Model ...........................................................4-2 Review the Business Enterprise Direction Model.........................................4-4 Mission Statement........................................................................................4-5 Establish the Business Vision ......................................................................4-9 Establish Business Objectives ...................................................................4-11

Requirements ..........................................................................................................5-1 Requirements ...............................................................................................5-2 Business Objectives .....................................................................................5-4 Business Requirements ...............................................................................5-5 Functional Requirements .............................................................................5-6 System Requirements ..................................................................................5-7 Technology Requirements ...........................................................................5-8

Table of Contents

II

Process Threads and Process Charts...................................................................6-1 Identifying Process Threads in the Organization..........................................6-2 Reviewing the Process Charts Already Built ................................................6-4 Create a New Process Chart Diagram.........................................................6-8 Specify the Process Thread Represented by the Process Chart .................6-9 Modeling the Process Flow of a Reservation Inquiry .................................6-11 Drawing Sequence Lines ...........................................................................6-14 Adding Swimlanes to the Process Chart Diagram .....................................6-17

Create More Swimlanes for Other Organizational Units .................6-19 Relating Roles to Processes ..................................................................................7-1

Introduction to Matrices ................................................................................7-2 The Event to Result Matrix ...........................................................................7-3 View the Results of Event-to-Result Matrix Correlations..............................7-6 Roles vs Elementary Business Processes...................................................7-7 Relating Roles to EBPs via a Matrix.............................................................7-8

Process Decomposition .........................................................................................8-1 To Create a New Process Decomposition ...................................................8-2 Add a Primary Process Group......................................................................8-3 Add Process Threads...................................................................................8-4 Update a Process Thread with EBPs ...........................................................8-6

Building a Functional Hierarchy ............................................................................9-1 Examine the Functions of the Business .......................................................9-2 Relate Business Processes to Functions.....................................................9-3 Create a Functional Hierarchy......................................................................9-5

Introduction to UML ..............................................................................................10-1 Object-Oriented Modeling ..........................................................................10-2 This Tutorial -- A Use Case-Driven Approach............................................10-3 Opening the Tutorial Encyclopedia.............................................................10-6 Setting Preferences....................................................................................10-9 Explanation of Some Preferences............................................................10-10

Modeling With UML Use Cases............................................................................11-1 How to Model with Use Cases -- Discussion..............................................11-2 Organize the Project with Packages ..........................................................11-4 Modeling Use Case Scenarios ...................................................................11-7 Create a Child UML Use Case Diagram ..................................................11-12

Drawing the Child Use Case Diagram...........................................11-13 Defining the Actors ...................................................................................11-15 Define a Use Case with Steps..................................................................11-16 Create an Includes Relationship Between Use Cases.............................11-20 Extend a Use Case ..................................................................................11-21

Table of Contents

III

Tracking Requirements Against Use Cases ............................................11-23 UML Sequence and Collaboration Diagrams .....................................................12-1

Sequence and Collaboration Diagrams......................................................12-2 Create Sequence/ Collaboration Diagrams................................................12-4

Finding Objects By Examining Use Case Scenarios ......................12-5 Create a Sequence Diagram......................................................................12-6

Adding Additional Objects to the Sequence Diagram .....................12-9 Draw Message/Stimulus Lines Between Objects..........................12-12 Show Object Creation ...................................................................12-15 Complete the Sequence Diagram .................................................12-16 Adding a Method to a Message Line.............................................12-19 Adding a New Method to a Class ..................................................12-21

Create Collaboration Diagram..................................................................12-23 Add a Message to a Link...............................................................12-24 Modify a Message .........................................................................12-26

Synchronize Sequence Diagram..............................................................12-27 UML Class Diagram...............................................................................................13-1

Create UML Class Diagram .......................................................................13-2 Begin a New UML Class Diagram..............................................................13-4 Building Relationships Between Classes ...................................................13-6 Defining an Association..............................................................................13-8 Adding Associations Between Other Classes ..........................................13-11 Building Inheritance..................................................................................13-12 Cross Referencing Class and Sequence Diagrams.................................13-15 Create a UML State Diagram ...................................................................13-18 Determine the States and Transitions for a Class....................................13-19 Drawing the State Diagram ......................................................................13-21 Defining a State........................................................................................13-24 Mapping the Class Diagram to an ER Model ...........................................13-26 Implementing the Design with Code (Java)..............................................13-28 Generating Java .......................................................................................13-29

Logical Data Modeling ..........................................................................................14-1 Logical Data Modeling................................................................................14-2 Creating a Subject Area of the Data Model................................................14-4 Creating a New ER Diagram ......................................................................14-5

Drawing Entity Symbols...................................................................14-7 Defining Entities ............................................................................14-10 Specifying Primary Keys................................................................14-13 Creating New Data Elements in an Entity .....................................14-15 Drawing Relationship Lines...........................................................14-17 Updating Foreign Keys..................................................................14-19

Table of Contents

IV

Creating a Second Subject Area Diagram ...............................................14-21 Creating a Model Diagram .......................................................................14-25

The Physical Data Model ......................................................................................15-1 The Physical Data Model............................................................................15-2 Creating the Physical Diagram...................................................................15-4 The Physical Table.....................................................................................15-8 Display Options for a Table ......................................................................15-11 Modeling Constraints Between Tables.....................................................15-12 Generating Schema .................................................................................15-13 Reversing Database Designs...................................................................15-15

Reporting System..................................................................................................16-1 Opening System Architect Encyclopedia....................................................16-2 Run a Pre-Written Report...........................................................................16-3 Create a New Report..................................................................................16-4

Select the Diagram Type.................................................................16-7 Select Diagram Properties to Print ..................................................16-9 Make Report Contain Symbols on Diagram..................................16-11 Select Entities As the Symbol Type...............................................16-12 Select Entity Definition Properties To Print ...................................16-13 Select Entity Definition Properties .................................................16-15 Use "Is A" Relationship .................................................................16-18 Final Report...................................................................................16-20

HTML Publishing Tutorial .........................................................................16-22 Opening The SA/HTML Generator................................................16-23

Select a Template Home Page ................................................................16-25 Select the Publish Home Page......................................................16-26 Selecting Diagrams .......................................................................16-27 Generate HTML.............................................................................16-29

View the Results.......................................................................................16-30

1-1

1 Introduction

Welcome to System Architect, the world's leading Enterprise Modeling Tool. In the this tutorial, we will tour through some of System Architect's extensive capabilities within Business Enterprise Modeling, UML, and relational data modeling techniques. We will examine the business operations of a fictional Hotel Chain, and undertake to build an e-Commerce Hotel Reservation System.

We will use a scenario of the Popkin Process as a road map to model this business, and as we model, we will create artifacts against cells of the Zachman framework.

Topics in this chapter Page The Project: An International Hotel Business 1-2

The Zachman Framework 1-3

The Popkin Enterprise Framework 1-5

Process Chart for Tutorial 1-6

Introduction

1-2

The Project: An International Hotel Business In this tutorial, we will examine a fictitious International Hotel Chain. For argument's sake, we'll call this company Chelsea Hotels and Resorts. We will take a look at the business as it currently stands, determine problems that exist, and state Business Objectives that we would like to realize. Then we'll map these Business Objectives into lower-level requirements, and build models to show how the business should run to satisfy these requirements. We will then undertake the project to build a new e-Business reservation system for the hotel, using business process modeling, application modeling with UML, and relational data modeling.

Chelsea is a chain of inns that has been around a number of years. The company has competed in the low-cost accommodations business segment by primarily providing rooms for cost-conscience families on vacation. The Restaurants business segment provides an on-site restaurant featuring home cooked food catering to families. The company has recently begun to expand its business, entering the resort business segment (and thus adding the word Resorts to its name), and the business travel segment. The management at Chelsea has realized that an effective Internet presence is crucial to compete in these business segments. Company management has determined that this does not simply mean designing a pretty site to introduce the company. The companies main focus is to examine business functions and processes, while making sure that the company is operating efficiently and without redundancy. They want to integrate a website into the business processes. As part of this effort, the company has determined that they want to build an effective on-line reservation system.

Chelsea's high-level business objectives can be summarized as stated:

• Create a market presence as a leader in resort travel • Create a market presence as an ideal solution for

business travel • Achieve Sales Growth of 20 % per year for next 5

years • Create efficient on-line Reservation System • Integrate website with improved business processes.

The Zachman Framework

1-3

The Zachman Framework The Zachman Framework for Enterprise Architecture, developed by John Zachman, provides a common vocabulary and set of perspectives-a framework-for defining and describing complex enterprise systems. It is a logical structure for classifying and organizing the elements of an enterprise that are important to both the management of the enterprise and the development of its information systems.

The Zachman Framework was initially published in 1987, and has evolved to become the model around which major organizations worldwide view and communicate their enterprise information infrastructure.

Not a Method, But a Tool for Thinking

The Zachman Framework is not a method, nor is it a specification for the diagram notations that should be used to capture information at various stages. It is simply a very important tool for thinking about the information that needs to be gathered about a business and its systems, for classifying that information, and for seeing how different parts of the enterprise need to share information.

The columns of the Zachman Framework specify the type of information to be captured - the who, what, why, when, where, and how of modeling a business and its systems. the rows of the Zachman Framework specify the stages of development - starting at Contextual, then Conceptual, then Logical, then Physical, then Implementation, and finally, Finished system.

Introduction

1-4

Figure 1-1 Zachman Framework.

The Popkin Enterprise Framework

1-5

The Popkin Enterprise Framework The Popkin Enterprise Framework maps each cell of the Zachman Framework to a System Architect diagram or definition. During this tutorial, we will use a subset of the diagrams and definitions in the Popkin Enterprise Framework to model the Chelsea Hotels and Resorts business. We will ' walk' a path through the framework, selecting various diagram and definition types to capture information about our business. The path that we walk, will be labeled a scenario. It is only one of a number of equally correct paths to walk.

Figure 1-2 Definitions and diagrams that map System Architect to the Zachman Framework.

Introduction

1-6

Process Chart for Tutorial The Popkin Process is a guide for building Enterprise systems with System Architect. A copy of it is installed with System Architect, and is located in the System Architect/Manuals directory. For this tutorial, we will use a scenario of the Popkin Process to model the Chelsea Hotels and Resorts business. We depict this scenario as a workflow diagram called a Process Chart. We will walk this scenario during this tutorial, using it as a road map, and taking a closer look at it.

Figure 1-3 Process Chart describing road map for this tutorial.

2-1

2 Getting Started

In this chapter we will create a new project, select the methods and notations we will use in this tutorial, and set the drawing preferences.

Topics in this chapter Page Starting System Architect 2-2

Creating/Opening an Encyclopedia 2-3

Set Preferences 2-6

An Explanation of Some Preferences 2-7

In this chapter…

Getting Started

2-2

Starting System Architect To start System Architect:

1. Run System Architect from the Start, Programs menu or double-click on the System Architect program icon. The product screen and the Audit Id dialog will appear.

2. In the Audit Id dialog box, type a personal identifier of up to 7 characters. This identifier will automatically be added to all diagrams and dictionary definitions you create or modify in your encyclopedia. Click OK.

Note: If you are using the network version of System Architect, you will not see the same Audit Id dialog box. Instead you will be asked to enter your network password which will be used in the place of your Audit Id.

Creating/Opening an Encyclopedia

2-3

Creating/Opening an Encyclopedia The System Architect encyclopedia is a relational database in a single sub-directory on your computer. Whether you're working on a stand-alone PC, or as part of a network in a client/server system, the relationship between the encyclopedia and a sub-directory is 1-to-1. That is, the encyclopedia is in a sub-directory; one sub-directory contains just one encyclopedia.

All the diagrams and all the definitions, both those associated with diagrams and those that aren't, are in the encyclopedia.

If you have several projects, you may have several encyclopedias, but that's entirely an individual decision. For example, you can build an enterprise encyclopedia in which you keep all the information relating to your company's standards as well as information that has been used in old projects. When the company decides to start a new project, such as an Accounts Payable (AP) system, those parts of the enterprise encyclopedia that should be used as a "leaping off point" for the AP system are exported to a new encyclopedia. And after the AP system is completed, some of the information discovered in the process of designing that system might be merged into the enterprise encyclopedia.


We will open an encyclopedia that has already been populated with some of the systems we will build. The project encyclopedia we will open for is called Tutorial.

Important Note: In this tutorial, we will model in the encyclopedia provided called Tutorial, using information already provided in it as a starting point. If other team members have already taken this tutorial and modified the Tutorial encyclopedia, you may want to start with a fresh version of this encyclopedia as a starting point. A zip file, Tutorial.zip, is provided in the Tutorial directory. It provides a fresh version of the Tutorial encyclopedia. You should unzip this file to a new path before beginning these exercises.

Getting Started

2-4

To open the Tutorial encyclopedia with System Architect:

1. From the File menu, select Open Encyclopedia.

The Encyclopedia Open dialog appears. The Samples encyclopedia within the Existing tab is selected by default.

2. Choose a project by selecting the Browse button on the Existing tab to reveal all of the project encyclopedias in this folder. Select the Tutorial encyclopedia and choose OK.

3. If not already selected, toggle on Load this project at

startup, located at the bottom left of the encyclopedia open dialog. This will make this encyclopedia the default encyclopedia that will automatically open each time you start the product.

4. Click OK to load the project.

Figure 2-1 Select and open Tutorial encyclopedia.


2-5

Property Configuration:

Next, let's take a look at the Property Configuration dialog box to see what methods, diagram types, and target languages are selected for this project encyclopedia. These can be changed at any time during the project.

1. Select Tools, Customize Method Support, Encyclopedia Configuration to open the System Architect Property Configuration dialog. You will notice that the encyclopedia has been configured for Entity Relation Data Modeling, Enterprise Business Modeling, and UML, among other things. We have chosen Oracle as the Target Database and Java as the Target Language as shown below.

Note: You can change the Property Configuration at any time using the Customize Method Support, Encyclopedia Configuration command from the Tools menu. After making changes you must reopen the encyclopedia for the changes to take effect.

Figure 2-2 Specify methods and properties to model with.

Getting Started

2-6

Set Preferences Now you are almost ready to begin the tutorial project. However, first you need to set your preferences for how System Architect will react to your drawing commands.

System Architect offers many optional drawing and tool behavior features. They can be turned on or off at any time with the Preferences dialog.

To set Preferences:

1. From the Tools menu, select Preferences. The Preferences dialog box appears.

2. In the preference Auto dialog, click number as displayed below.

3. Click OK to close out the preferences dialog.

Figure 2-3 Set preferences for drawing and behavior.

An Explanation of Some Preferences

2-7

An Explanation of Some Preferences Here are explanations for some of the major settings chosen in the picture on the previous page:

Note: For a fuller explanation of the Preferences dialog, go to the Help menu and select Help for the On-line Help System. You can also find this information in your System Architect User Guide or System Architect Tutorial manual, as well.

3-1

3 Creating a Business Profile

Our first step in modeling Chelsea Hotels and Resorts is to establish what the business is currently about. We will capture some of this information in a Business Profile definition. Within this definition, we'll get a handle on the company's products, services, customers, suppliers, competitors, the business segments it operates in, and other forces impacting the business.

In this chapter we will establish a Business Profile for the hotel. This process will clarify areas on which the business needs to focus. In essence, we will lay the foundation on which to develop our business vision.

Topics in this chapter Page Defining a Business Profile. 3-2

Review the Business Profile Definition 3-4

The Business Segment Profile 3-6

Reviewing the Products and Customers 3-9

Customers Profile 3-11

Reviewing Suppliers and Competitors 3-13

Business Forces Summary 3-15

What is a Business Profile?

In this chapter…

Creating a Business Profile

3-2

Defining a Business Profile The picture below shows where we are in the business modeling scenario that we are following for the tutorial.

In summary, the Business Profile will contain the following information:

Business Segments Profile summarizing key information about the different lines of business or market segments.

Products and Services Profile summarizing key information about the different product and service categories within each business segment to be considered further.

Customers Profile summarizing key information about the different customer types within each business segment that will be considered further.

Defining a Business Profile

3-3

Suppliers Profile summarizing key information about the different supplier types used by the company.

Competitors Profile summarizing key information about the competitors within each business segment.

Business Forces Summary highlighting the financial, regulatory, and other forces that impact the company. This identifies any pressures or constraints imposed on the company that restrict freedom or suggest a focus for business change in redesigning business processes or organizational structure.


3-4

Review the Business Profile Definition Let's examine the Business Profile for Chelsea already created in the Tutorial encyclopedia.

1. Select the All Methods tab in the browser, and click on the + mark next to Definitions, to reveal a list of all definition types. (Note: if your browser has been narrowed in width, the All Methods tab will be truncated to All).

2. Click on the + mark next to Business Profile, to reveal the Chelsea Hotels and Resorts definition.

Figure 3-1 Open the Business Profile definition for Chelsea Hotels and Resorts.

Review the Business Profile Definition

3-5

3. Double click on the definition Chelsea Hotels and Resorts or right-mouse click on it and select Open.

The definition dialog for Chelsea Hotels and Resorts opens, as shown below.

Notice that there are four tabs of information for the business profile. The first tab provides a text box for Description. You will see a Description text field in just about every definition type that you run across in System Architect. It provides you with a place to put a general text description of the item. In the upcoming sections we will examine and add to the information in the Business Profile definition.

Figure 3-2 View the Business Profile definition.


3-6

The Business Segment Profile The first tab of the Business Profile definition provides a list of Business Segments. Every business operates within one or more business segments. Within each business segment conditions will vary, including the competition, types of customers, profit margins, and marketing approach. For example, Chelsea Hotels and Resorts operates in the Accommodations segment and the Leisure segment. As we mentioned in the previous chapter, they are looking to get into the Resort segment and the Business Travel segment. Within the Business Travel segment, hotel services, customers, competitors, and marketing approach will be different than the Accommodations segment. Note: In the Business Segments list box, notice that Accommodations and Restaurants are already listed. To review information about these segments, select the segment and click on the Define button at the bottom of the list box.

Let's add the two business segments that Chelsea is now trying to compete in - Business Travel and Resorts. One of these segments, Resorts, is already defined in our project encyclopedia -- we will reuse it. The other segment, Business Travel, we will add anew.

1. Under Business Segment Profile, click on the Choices button in the lower right corner of the dialog. The Select and Drag dialog gives you a list of all definitions of this type already in the project encyclopedia.

2. Right-mouse click anywhere on the white area in the Select and Drag dialog and click on Details to open a window that provides a summary of each item as you select it.

3. Select and hold (with your left mouse button) the Resorts business segment and drag it into the top of the list, then release it so that it is added to the list. Once added, you may highlight Resorts and click on the Define button to see its full definition.

The Business Segment Profile

3-7

Figure 3-3 Reuse a business segment definition from the underlying repository.


3-8

Adding a New Business Segment

You can (optionally) add a new business segment to the project. 1. Place your cursor in the top line of the Business Segment

Profile list box and type in Business Travel, then click Add.

2. To define the Business Travel business segment, highlight it and click the Define button.

3. Complete the appropriate sections of the dialog with the information provided below:

Description

Certain hotels will be targeted toward the business traveler.

Characteristics

All accommodations are geared toward business traveler - all rooms include phone data link, iron and ironing board, free copy of local daily newspaper, and continental breakfast.

Critical Issues

In the U.S., the price should conform to government per-diem allowances.

4. Click OK. You will return to the Business Profile definition dialog.

Reviewing the Products and Customers

3-9

Reviewing the Products and Customers To understand the business, you must fully understand what your Products are and who your Customers are. Let's take a look at those already entered in the business profile definition for Chelsea Hotels and Resorts.

1. Click on the Products and Customers tab, and look at the Products/Services list box. You can look at the definitions behind the products listed (Restaurants, Leisure Facilities, and Conferences) at your leisure, but for this tutorial, we will examine Rooms.

2. Select Rooms and click Define, to open the definition

dialog for Rooms.

Note that a product/service type, in this case Rooms, includes a brief description (as does every definition type in System Architect), key characteristics, and critical issues. A product/service may also be categorized.

Figure 3-4 Review the products and customers of the hotel chain.


3-10

Categories: You may categorize a product, service, or customer. In this example Rooms are categorized into standard rooms, suites, and business traveler rooms. We might also categorize rooms into smoking rooms, non-smoking rooms, rooms with king-sized beds, rooms with two double beds, etc.

For the Room product, you can see that rooms in the hotel have been categorized into three different types - Suites, Standard Room, and a new category invented to cater to the business traveler - a Business Traveler Room.

3. Select Business Traveler Room, and click on Define.

4. View the pages of this definition - you will notice a brief description of what this room should provide, and a description of the needs and values of the customer to this product. On page 2 of this definition, the relative size and growth of this type of product are described in very general terms.

5. Click OK to close the Business Traveler Room dialog.

6. Click OK again to close the Products/Service Profile – Rooms.

Customers Profile

3-11

Customers Profile A hotel has many types of customers - you should distinguish them by major types, and then categorize within those types. For example, there are business travelers and vacationers. For vacationers, you might categorize by budget-minded vacationers, Resort vacationers, and honeymooners. You might also list major customers independently, especially if they exert a certain influence on the hotel by themselves.

Let's take a look at Vacationers:

1. Within the Customers Profile dialog, select Vacationers and press Define as shown below. The Customer Profile -- Vacationers definition dialog appears.

Defining the Customers

Notice that Vacationers have been categorized by Honeymooners, Budget-minded Vacationers, and Resort Vacationers. Each of these different types of customers will have very different needs and values. For example:

2. Select Resort Vacationers and click Define.

Notice that this type of customer has very special values and needs that you need to accommodate if you hope to succeed in this business segment.

Figure 3-5 Open the definition of a customer profile.


3-12

3. Click OK to close the Resort Vacationers dialog, and the

Vacationers dialog, to get back to the Chelsea Hotels and Resorts Business Profile dialog.

Figure 3-6 View the definition of the Resort Vacationers category.

Reviewing Suppliers and Competitors

3-13

Reviewing Suppliers and Competitors An important part of understanding the business is understanding who your suppliers are and how dependant you are upon them, and who your competitors are, and how and in what markets you compete against them. Oftentimes, a competitor can also be a supplier and also a customer, or even a partner.

Suppliers Profile

Let's take a look at a supplier:

1. Click on the Suppliers and Competitors tab.

2. Tribeca Textiles is listed in the Suppliers Profile list box. Select it and press the Define button at the bottom of the list box.

Definition of the Supplier 3. Review the tabs of information that have been gathered

about this supplier:

• Critical Issues are listed in the Characteristics tab.

• This supplier has established business with Chelsea Hotels and Resorts by competitive procurement, which is modeled in the Relationship tab.

• This supplier only delivers on Tuesday and Friday mornings -- this is modeled in the Relative Power tab, as Suppliers Can Impose Processes.

4. Click OK to close the Suppliers Profile dialog.

Competitors Profile

Within the Competitors Profiles list box you may list individual competitors, or competitor types. There are already two listed for Chelsea Hotels and Resorts - Bed and Breakfasts and Major Hotels.

Let's take a look at a competitor:

5. Under Competitors Profile, select Bed and Breakfasts and press Define as shown below.


3-14

Definition of the Competitor

6. Review the tabs of information that have been gathered about this competitor and then click OK to close the Bed and Breakfasts competitors profile.

Figure 3-7 Open the definition of a competitor profile.

Business Forces Summary

3-15

Business Forces Summary Within the Business Forces section of the business profile, you try to get a handle on the financial, regulatory, and other business forces affecting the company. You create one Business Forces profile for the company.

Defining the Business Forces Summary

Let's take a look at the business forces affecting Chelsea Hotels and Resorts:

1. Click on the Business Forces Summary tab.

2. Select Chelsea Business Forces and click on the Define button. Tour the various tabs of the definition and view the textual information summarizing some of the business forces at work.

3. Close all dialogs by clicking OK to each one.

Figure 3-8 View the business forces summary.

4-1

4 Establish the Business Enterprise Direction

A Business Enterprise Direction Model analyzes the strategy of the business, including the mission, business objectives and goals, critical success factors, critical business issues, and specific strategies.

In this section of the tutorial we will establish the Business Enterprise Direction of Chelsea Hotels and Resorts. In the last section we established its Business Profile -- what it currently does; now we will establish where we want to take the business.

Topics in this chapter Page

Business Enterprise Direction Model 4- 2

Review the Business Enterprise Direction Model 4-4

Mission Statement 4-5

Establish the Business Vision 4-9

Establish Business Objectives 4-11

What is the Business Enterprise Direction? In this chapter…

Establish the Business Enterprise Direction

4-2

Business Enterprise Direction Model The next step in Contextual modeling that we will perform is to examine the Business Enterprise Direction for the hotel chain. We want to establish the high-level goals of the business, the business objectives, mission statement, etc. Information entered here will set the context of the modeling we will do. This information can later be disseminated through automatic reports. The picture below shows where we are in the business modeling scenario that we are following.

General

The Business Enterprise Direction Model analyzes the strategy of the business. It covers the future business vision and the accompanying case for action. With the framework of the model you will identify the key business policies and rules that govern the choices for business change. The Business Enterprise Direction Model consists of the following components:

Mission Statement -- a brief, succinct declaration of what the enterprise exists to do. It should identify the enterprises purpose, general product lines, target customer segments, and intended level of performance.

Business Objectives -- specific results or long-term objectives that the enterprise wants to achieve in a three- to five-year time period, usually via a series of shorter-term goals. The objectives, generally between five and ten, should be measurable and state specific measurements of success.

Business Enterprise Direction Model

4-3

Specific Strategies -- represent the direction the enterprise will take to achieve its Business Objectives. The strategies state how the objectives will be achieved and are therefore subordinate to the objectives themselves.

Critical Success Factors (CSFs) -- a few key circumstances, generally ten or fewer, that must occur in order for the enterprise to fulfill its mission.

Critical Business Issues (CBIs) -- opportunities, problems, trends, competitive threats, or regulatory situations causing the enterprise to take action at the current time.

Balanced Scorecard -- a one-page summary of the most critical measures of the company, grouped into four perspectives: 1) Customer, 2) Internal business, 3) Innovation and learning, and 4) Financial.

Case for Action -- may apply on an enterprise level or on a business area level. This is a clear and succinct summary of the primary business issues that have led to the current initiative and are raising the sense of urgency for change.

Business Vision -- may apply to the entire enterprise or to a specific business area. This describes what it will be like when the transformations within this area are complete.

Key Business Policies -- statements that identify the major policies necessary for the new system concepts to work.

Business Rules Comparison -- identifies old unwritten rules and assumptions under which the business area has operated in the past and possible new rules under which it will operate in the future.


4-4

Review the Business Enterprise Direction Model Let's examine the Business Enterprise Direction for Chelsea already created in the Tutorial encyclopedia:

1. Select the All Methods tab in the browser, and click on the + mark next to Definitions, to reveal a list of all definition types.

2. Click on the + mark next to Business Enterprise Direction, to reveal the Chelsea Hotels and Resorts definition. Double-click on this definition or right-mouse click on it and choose Open. The definition dialog for the hotel's Business Enterprise Direction appears. We will fill in some of the information.

Figure 4-1 Open the Business Enterprise Direction definition.

Mission Statement

4-5

Mission Statement What is the mission of the company? Why does the company exist -- what good does it hope to achieve. If the leaders of the company have a mission in mind, do the employees have a clear understanding of what it is? Do the customers know?

Before undertaking any more modeling of the business, we will define the mission statement of Chelsea Hotels and Resorts.

The first page of the Mission Statement tab of the Business Enterprise Direction dialog contains the generic Description property as well as the Mission Statement and Specific Strategies. By default, every definition dialog in System Architect contains a description property - you generally enter general information concerning this definition in itself; in this case we might enter some text concerning this Business Enterprise Direction definition - for example, is this the Business Enterprise Direction for the whole company or just a division; is it a suggested direction or is it clad in stone, are there time limits to it, etc. The Description property just happens to fall within the Mission Statement tab, which is for the overall Business Enterprise Direction definition.

1. Examine the Description field of the Business Direction of Chelsea Hotels and Resorts. It contains the following text:

This sets forth the Business Enterprise Direction for the next 5 years.

2. From examining the Business Profile, we now have a good feel for what the company currently does. Examine the Mission Statement for Chelsea Hotels and Resorts. You can change it if you like, but what we've filled in is:

We will provide the business traveler with a consistently excellent experience at a moderate cost. We will also provide premier resorts for vacation travel.

3. Examine the high-level Specific Strategies listed for how Chelsea will attempt to achieve this mission:

Marketing, pricing, and accommodations will be targeted to business travelers. We will increase participation in conferences in hotels located in major conference cities.

Description

Mission Statement


4-6

Now let's examine Critical Success Factors (CSF) and Critical Business Issues (CBI) of Chelsea Hotels and Resorts.

Critical Success Factors Critical Success Factors (CSFs) are key circumstances that must occur in order for the enterprise to fulfill its mission. There are generally no more than 10 CSF's for a business, each described by five to ten statements describing what the enterprise wishes to achieve.

1. Within the Business Enterprise Direction definition, click on the CSF/CBI tab. Take a look at the first page of this tab, in which the Critical Success Factors are listed.

2. Click on the small rectangle in the bottom right-hand corner of this dialog to expand the list.

Figure 4-2 Business Enterprise Direction definition.

Critical Success Factors/Critical Business Issues

Mission Statement

4-7

3. View the critical success factors listed:

� Business Traveler Repeats � Beach-front properties for Resorts � Strong partnerships with Travel Agents � Be recognized as leading resort hotel

Critical Business Issues Critical Business Issues are opportunities, problems, trends, competitive threats, or regulatory situations requiring action or resolution.

Let's examine some of the Critical Business Issues for Chelsea:

4. Within the CSF/CBI tab, click on the page arrow in the top of the dialog to move to page 2, revealing a list of Critical Business Issues:

Figure 4-3 Examine Critical Business Issues.


4-8

5. View the critical business issues listed:

� On-line reservation system is mandatory � Interest rates are rising globally � Exchange rate in South America

A Case for Action

A Case for Action is a clear summary of the primary business issues leading to this initiative and raises the sense of urgency for change.

6. Examine the Case for Action:

The company has experienced no real growth over last eight years. Market surveys show company is known for moderate accommodations in dated facilities that appeal most to cost-conscience family vacationers. Hotel rankings are very low in two fastest growing travel market segments - business travel and premier resort accommodations.

Establish the Business Vision

4-9

Establish the Business Vision In the next section of the Business Enterprise Direction dialog we'll take a look at the Business Vision, Key Business Policies, and the Business Rules Comparison.

The Business Vision describes the future vision of the business enterprise.

1. Within the Business Enterprise Direction definition, click on the Business Vision tab, and view the information.

Business Vision: The hotel will become a major force in the areas of business travel and exotic resort vacations. The hotel name will become synonymous with an elegant, professional atmosphere for the business traveler at moderate rates. Business travelers will take their families back to the hotel and to its resorts for vacations.

Key Business Policies: Web site will be the most advanced in the field for reservations. Its content will reflect the business vision. It will become a site that the casual web surfer will go to for travel.


4-10

Business Rules Comparison In Business Rules Comparison, we record the present state and future state of business rules as we identify, challenge, and redefine them based on the new enterprise direction.

Take a look at the Business Rules Comparison:

2. Examine the Old Rules.

Rely on established base of family vacationers.

3. Examine the New Rules.

Recruit business travelers to return for vacations.

Figure 4-4 Examine the Business Vision.

Establish Business Objectives

4-11

Establish Business Objectives From the Introduction to the Hotel Example, we started with five business objectives:

• Create a market presence as a leader in resort travel

• Create a market presence as an ideal solution for business travel

• Achieve Sales Growth of 20 % per year for next 5 years

• Create efficient on-line Reservation System

• Integrate website with improved business processes

These business objectives should be part of Chelsea's Business Enterprise Direction. Let's add them:

1. Return to the Mission Statement tab of the Business Enterprise Direction definition, and click on the Page arrow in the top of the dialog to move to page 2, revealing an empty list box for Business Objectives.

2. Enter the business objectives listed above by typing each one in and pressing Add (do not include any periods as you type).

3. Click OK to close the Business Enterprise Direction dialog.


4-12

Figure 4-5 Open the Business Enterprise Direction.

5-1

5 Requirements

The purpose of our modeling effort is to capture requirements for the business, and make sure that those requirements are met by the processes we have in place and the systems we build. Generally, there are many levels of requirements, starting with high-level business objectives, which fan out into business requirements, which fan out into system requirements, which fan out into technology requirements, etc. System Architect enables you to capture these and other requirement types, and attach them to your models. Later, you can run reports or view matrices to see what the requirements are, how they have been met, and if one changes, what parts of the system are affected.

We will establish the business objectives for our hotel business example, and look at how we will capture lower-level requirements.

Topics in this chapter Page Requirements 5-2 Business Objectives 5-4 Business Requirements 5-5 Functional Requirements 5-6 System Requirements 5-7 Technology Requirements 5-8

Business Objectives and Multi-Level Requirements

In this Chapter…

Requirements

5-2

Requirements As we model Chelsea Hotels and Resorts, we must be aware of our high-level business objectives. Business objectives will result in a more refined set of business requirements. The business requirements must be fulfilled by the business processes and data that the processes deal with. Business requirements will later yield functional requirements for the systems that we build.

As we move to design, the functional requirements will yield systems requirements, and as we move to implementation of the systems, we will deal with technology and architectural requirements.

Out of the box, System Architect provides Business Objective and Requirement as definition types. Since Popkin Software cannot possibly know what each customer wants to capture as properties of a requirement, both of these definitions present a suggested property set (ie, for a Requirement, you may enter Source Document, Author, etc). Each user will generally have their own particular properties that they need to capture. In addition, each user generally has different terminologies for lower-level requirements - for example, in this tutorial we will talk about Functional, System, and Technology requirements - but this will not be what every user calls lower-level requirements in their organization.

To facilitate this, we will use System Architect's ability to create new definition types, and modify the properties of existing definition types, with its customizable metamodel and USRPROPS.TXT.

A full explanation of USRPROPS.TXT is provided in the help system and the User Guide. For now, we want to establish a few basic rules on how you would handle requirements in your organization with USRPROPS.TXT and System Architect.

Basic Rules for Requirement Capture with USRPROPS.TXT

The basic rules for requirement capture with USRPROPS.TXT are:

� Decide upon what requirement types you will be gathering - for example, Business Objectives, Business Requirements, Functional Requirements, System Requirements, etc.

� For each new Requirement type definition, establish the properties for that requirement type that you will be capturing.

� Decide what model elements you will be associating requirements against.

Requirements

5-3

� Make sure the requirements are fulfilled by running requirements tracing reports.

Traceability of Requirements through Multiple Levels

The Tutorial encyclopedia comes with a pre-loaded USRPROPS.TXT. We have created a few new requirement types. System Architect comes with the types Business Objective and Business Requirements by default.

We have added the following requirement types:

� Functional Requirement

� System Requirement

� Technology Requirement

What's more, we have created links between these requirement types, so that you can add a Technology Requirement to the project encyclopedia, and see what System Requirement it came from, and for that System Requirement, see what Functional Requirement it came from, and for that Functional Requirement, see what (Business) Requirement it came from, and from that Requirement, see what Business Objective it came from. We are establishing traceability of our requirements.

Requirements

5-4

Business Objectives Remember that we started with five high-level business objectives that were introduced in the Introduction chapter. We added these to Chelsea's Business Enterprise Direction definition in the previous section. They are now a part of our project.

Our business objectives are:

� Create a market presence as a leader in resort travel

� Create a market presence as an ideal solution for business travel

� Achieve Sales Growth of 20 % per year for next 5 years

� Create efficient on-line Reservation System

� Integrate website with improved business processes.

Business Requirements

5-5

Business Requirements Our high-level Business Objectives can be decomposed into a more granular set of Business Requirements. We will build processes to make sure these requirements are met.

A sample of some Business Requirements are:

� Provide Secure Transactions

� Create Web Access for Hotel Reservations

� Have Stable Web Site

� Capture Sales Leads From Web Site

� Retrieve Credit Card Information From Customer

These business requirements have already been added to the Tutorial encyclopedia, as Requirements.

1. In the All Methods tab, expand the Definitions list by clicking on the + mark to its left, and find Requirement.

2. Expand the Requirement list by clicking on the + mark to its left. View the requirements already in this encyclopedia.

We will use these requirements later.

NOTE: Later in this tutorial, we have made provisions (through USRPROPS.TXT) to assign Business Requirements to Elementary Business Processes in our Process Charts.

Figure 5-1 Requirements already in Tutorial encyclopedia.

Requirements

5-6

Functional Requirements As mentioned previously, we used System Architect's customizable metamodel and USRPROPS.TXT to create new definition types for the other requirement types that we are interested in - Functional Requirements, System Requirements, and Technology Requirements.

Functional Requirements

A spreadsheet in .csv format is provided with a list of Functional Requirements. This spreadsheet is named require.csv and is located in the <c>:\Program Files\Popkin Software\System Architect\Encyclopedias\Samples directory. We will access this list later in the tutorial. In fact, you may have already done so if you took the Quick Start tutorial. Some of the functional requirements that we will track are:

Requirement # 1:

Description: Explain hotel terms to all customers; customer must agree to abide by terms to stay at hotel.

Requirement # 2:

Description: Customer must confirm reservation 48 hours prior to stay. If reservation request is made within 48 hours of reservation date, customer must confirm at time of reservation request.

Requirement # 3:

Description: Customer must have proper credit to cover cost of room; credit checked at reservation time.

Requirement # 4:

Description: Must provide 15-percent discount for senior citizens (65 years old or older).

Requirement # 5:

Description: No pets allowed.

NOTE: In this tutorial, we have made provisions (through USRPROPS.TXT) to assign Functional Requirements to UML Use Case Steps. At this point in the tutorial, you don't have to do anything with the above functional requirements.

System Requirements

5-7

System Requirements We want to track System Requirements against the systems we are building. A sample of some System Requirements are:

� System Can Handle 300 Hits per second.

� Web site must be viewed with same graphical look on all common browsers.

These system requirements have already been added to the Tutorial encyclopedia.

1. In the All Methods tab, expand the Definitions list by clicking on the + mark to its left, and find System Requirement.

2. Expand the System Requirement list by clicking on the + mark to its left. View the requirements already in this encyclopedia.

NOTE: In this tutorial, we have made provisions (through USRPROPS.TXT) to assign System Requirements to UML Classes and Components in UML Class and Component diagrams, respectively.

Figure 5-2 System Requirements already in Tutorial encyclopedia.

Requirements

5-8

Technology Requirements We want to track Technology Requirements against the technology we are using for the systems we will implement. A sample of some Technology Requirements are:

� Web Server must have 256M Ram.

� Web Server must use Windows NT operating system

� Scripts running on server must be compatible with NT

These technology requirements have already been added to the Tutorial encyclopedia

1. In the All Methods tab, expand the Definitions list by clicking on the + mark to its left, and find Technology Requirement.

2. Expand the Technology Requirement list by clicking on the + mark to its left. View the requirements already in this encyclopedia.

NOTE: In this tutorial, we have made provisions (through USRPROPS.TXT) to assign Technology Requirements to nodes in UML Deployment diagrams.

Figure 5-3 Technology requirements already in Tutorial encyclopedia.

6-1

6 Process Threads and Process Charts

Every organization has a certain number of major and minor process threads. A process thread is modeled with one or more Process Chart diagrams. In the Process Chart diagram you model the workflow of your business in terms of Events, Elementary Business Processes, and Results. The flow between these elements is modeled with two types of lines -- Optional and Mandatory.

In this section, we will analyze a process thread that occurs in the organization - making a reservation - and represent the workflow for part of it with a Process Chart diagram. We will add swimlanes to the diagram to show where in the organization that the events and processes occur.

Topics in this chapter Page Identifying Process Threads in the Organization 6-2 Reviewing the Process Charts Already Built 6-4 Create a New Process Chart Diagram 6-8 Specify the Process Thread Represented by the Process Chart

6-9

Modeling the Process Flow of a Reservation Inquiry 6-11 Drawing Sequence Lines 6-14 Adding Swimlanes to the Process Chart Diagram 6-17

What are Process Threads and Process Charts?

In this section…

Process Threads and Process Charts

6-2

Identifying Process Threads in the Organization In terms of the scenario that we are following, we will accomplish the processes in bold below, identifying the process threads and representing the 'to be' business processes of the hotel example in Process Chart diagrams.

Functions, Organizational Units, and Processes

A hotel chain is a large organization that has an enormous amount of tasks going on. There is maintenance of the hotels themselves (including building maintenance, gardening, etc), human resources, marketing, reservations, etc. Each of these can be considered major functions of the hotel - ie, the hotel performs these functions. Sometimes a division or a department (in general terms an organizational unit) will perform a function by itself (ie, the human resources department performs the human resources function).

Identifying Process Threads in the Organization

6-3

Oftentimes, however, multiple departments will combine to perform a function. A process is how one or more organizational units performs a function.

Process Threads, Process Charts, and Elementary Business Processes

Within every organization there are a number of major process threads going on (generally on order of four to six), and within each major process thread, there are many minor process threads. Every process thread is modeled with one or more Process Chart diagrams. A Process Chart diagram is a process flow diagram on which you model business events, ensuing processes, and results.

Let's establish some major process threads and some minor process threads for Chelsea Hotels and Resorts. During the contextual stage of modeling, we may brainstorm to arrive at these threads, and enter them directly into System Architect as definitions.

Major Process Threads

Within Chelsea Hotels and Resorts, we can quickly come up with some major process threads:

For Reservations:

• Reserve Rooms

• Reserve Conference Rooms

For Marketing:

• Advertise Hotel

• Run Marketing Programs - ie, Rewards program

For Human Resources:

• Hire Personnel

• Fire Personnel

• Provide Benefits

Minor Process Threads

Let's think of some minor process threads that exist within the major process thread, Reserve Rooms:

• Reservation Accepted • Reservation Inquiry (reservation not made) • Reservation Cancelled • Reservation Confirmed • Check Customer Credit


6-4

Reviewing the Process Charts Already Built Let's take a look at some of the Process Charts already built in the Tutorial encyclopedia.

1. Select the BP (Business Process) tab in the browser.

2. Click on the + mark next to Diagrams to show the diagram list.

3. Click on the + mark next to Process Chart to reveal the list of Process Chart diagrams.

4. Single click on any of the diagrams in the list and view a thumbnail picture of the diagram in the Browse Details window at the bottom of the browser.

Reviewing the Process Charts Already Built

6-5

5. To view the diagram's informational details rather than the

thumbnail picture in the Browse Detail window, right-mouse click on any white space within the browser, and click off Pictures in the drop-down list as shown below.

Figure 6-1 View thumbnail sketch of each diagram in Details window.


6-6

6. Single-click on any of the diagrams in the list again -- now

you will see textual diagram properties in the Browse Detail window at the bottom of the browser instead of the picture. Using this method, you can quickly see information on each diagram, such as the Process Thread that each Process Chart diagram represents.

7. Open the Check Customer Credit diagram, by double-clicking on it or right-mouse clicking on it and selecting Open.

The Process Chart diagram contains Events (right-pointing arrows), Results (left-pointing arrows), and Elementary Business Processes (boxes). They are drawn within lanes called Swimlanes. Each swimlane represents an organizational unit within the company in which the event or result takes place, or the process is performed.

Figure 6-2 Toggle off Pictures to browse information about each diagram and symbol.

Reviewing the Process Charts Already Built

6-7

Figure 6-3 Process Chart diagram.


6-8

Create a New Process Chart Diagram Let's create a new Process Chart diagram to model the processing of a reservation inquiry:

1. From the File menu, select New Diagram. The Select new type for All Methods dialog opens.

2. Double-click on Process Chart from the list of diagram types.

3. In the New Diagram dialog that opens, type Process Reservation Inquiry and click OK to create the new diagram.

The new diagram is created, and a blank workspace is presented to us. By default, a starting swimlane is created on the diagram in the upper left corner. We will begin modeling with swimlanes off - we will turn them off in the steps that follow.

Figure 6-4 Create new diagram.

Specify the Process Thread Represented by the Process Chart

6-9

Specify the Process Thread Represented by the Process Chart First, let's specify the Process Thread that this diagram will represent.

1. Right-mouse-click anywhere in the white area of the diagram workspace, and select Diagram Properties from the drop-down list. The Process Reservation Inquiry diagram appears.

Specify the Process Thread that this Diagram Represents 2. In the Process Thread field, type in Reservation Inquiry

and click Define. You have just added a new process thread to the project encyclopedia. We do not have to add details to it now, simply click OK to close the Process Thread definition dialog and return to the Diagram Properties dialog.

Note: You don't necessarily have to perform the above step. When you save a Process Chart diagram, System Architect automatically creates a Process Thread definition with the same name as the diagram and enters this Process Thread reference in the diagram's properties. However, you would certainly want to perform the above step if the process thread your diagram was referencing had a different name than that of the diagram.

Figure 6-5 Default swimlane.


6-10

Turn Swimlanes Off

3. In the Diagram Properties dialog, select none for the Swimlanes property and click OK to close the dialog. System Architect will ask you "Shall I remove the swimlanes?". Click OK.

Modeling the Process Flow of a Reservation Inquiry

6-11

Modeling the Process Flow of a Reservation Inquiry Processing a Reservation Inquiry

When a customer requests a reservation, whether it is via the phone or the company web site, we must first store information about the customer. On the website we will probably request this information through an entry form. Once we have the customer information and the information that the customer requests (room type, location of hotel, and dates of requested stay), we will check to see if the room is available. If it is, we will provisionally book the room, and then ask verify the customer's credit before we actually reserve it. If the room is not available, we want to store the information about the room/date that the customer has requested (for marketing feedback information) and then inform the customer that the room is not available. It will then be up to the customer to decide whether they want to try for another date or hotel location.

In this process flow, we have a business event - customer requests reservation. This event triggers a number of processes - store customer details, check room availability, and store reservation request information for marketing. There will be one of two results occurring because of this flow - we will either provisionally book the room or we will notify the client that the room is unavailable. Verifying the customer's credit is already modeled in another Process Chart diagram (see Check Customer Credit).

Let's model this process flow.

Events

An Event is an occurrence that triggers a business to commence a process. To model the event Customer Requests Reservation on the Process Chart diagram:

1. In the Toolbox or Draw menu, find the Event symbol (the

arrow pointing to the right ). Select the symbol and release your mouse - your cursor will turn into a drawing pen when it is over the diagram workspace. Left mouse click and release on the drawing workspace to draw the event symbol.

2. Name this Event, Customer Requests Reservation, and press Enter.


6-12

Processes

A Process is a function or task that occurs over time and has an objective result. Let's draw three process symbols on a Process Chart diagram to represent the processes Store Customer Details, Check Room Availability, and Store Marketing Information in Database.

1. In the Toolbox or Draw menu, select the Process symbol (release your mouse - your cursor will turn into a drawing pen when it is over the diagram workspace). Left mouse click and release on the drawing workspace to draw the first process symbol.

2. Name the symbol Store Customer Details and press the Enter key.

3. Add another Process symbol to the right of Save Customer Details. Name it Check Room Availability and press Enter.

4. Add a third Process symbol, below Check Room Availability, and name it Store Marketing Info in Database.

Figure 6-6 Begin Process Chart diagram.

Modeling the Process Flow of a Reservation Inquiry

6-13

Results

A Result is an outcome of the business in response to an Event. To draw a result symbol on a Process Chart diagram:

1. In the Toolbox, find the Result symbol, and select and draw it on the diagram to the right of the processes drawn.

2. Name the Result symbol Provisionally Book Room and press Enter.

3. Directly below Provisionally Book Room add another Result, name it Notify Customer of Unavailability, and press Enter.


6-14

Drawing Sequence Lines Line symbols are used to interconnect the rectangular drawing symbols and denote the sequence path. There are two types of line symbols on a Process Chart diagram -- Mandatory Sequence lines and Optional Sequence lines. A Mandatory Sequence states that the proceeding process must be performed while the Optional Sequence states that the execution of the proceeding process is optional.

Mandatory Sequence Lines

We will draw Mandatory Sequence lines between the event Customer Requests Reservation and the process Store Customer Details. We will draw another Mandatory Sequence line between the process Store Customer Details and the process Check Room Availability:

1. In the Toolbox, find the Mandatory Sequence line and select it.

2. Place the cursor inside the Customer Request Reservation event and click once so that you get a + connector indicator. Release your mouse.

3. Move your cursor over to the Store Customer Details process to get a + connector indicator. (See picture below -- you should now have a + indicator at both ends of the mandatory sequence line.) Left click your mouse to connect make the connection between the symbols. The default name Mandatory_Sequence_1 appears on the line. Type over this default name, and name the line Customer Info.

4. Using the same procedure, draw another Mandatory

Sequence line from the Store Customer Details process to the Check Room Availability process. Name the line Check Availability press Enter.

Figure 6-7 Drawing Sequence line.

Drawing Sequence Lines

6-15

Optional Sequence lines

When we Check Room Availability, the room will either be available, in which case the event Provisionally Book Room will happen, or the room will not be available, in which case we want to take down information about this failed request anyway (for marketing purposes) before telling the customer the room is not available. We will use Optional Sequence lines to model this:

5. In the Toolbox, select the Optional Sequence line.

6. Place your cursor (which should look like a drawing pen) inside the process named Check Room Availability and click once so that you get a + connector indicator. Release your mouse.

7. Move your cursor to the result Provisionally Book Room until you get a + connector indicator. Name the new line Room Available and press Enter.

8. Using the line drawing procedure described in steps 2 and 3 above, draw another Optional Sequence line between the Check Room Availability process and the process Store Marketing Info in Database. Name the new line Room Not Available.

9. Now select the Mandatory Sequence line in the toolbar and draw a mandatory sequence between the process Store Marketing Info in Database and the result Notify Customer of Unavailability. Name the line Notify Customer.

Adding a Documentation Block

System Architect provides a simple automatic documenting feature called the Documentation Block. This symbol is provided in every diagram type's toolbar; simply adding it to the diagram will provide a time stamp of when the diagram was created. You may add comments about the diagram in the Doc Block's definition.

10. Select the Doc Block symbol in the toolbar (rectangle with initials DB in it) and place it below the customer requests reservation event symbol as shown below.

You should now have a diagram similar to the one shown below.


6-16

Figure 6-8 First cut Process Chart diagram.

Adding Swimlanes to the Process Chart Diagram

6-17

Adding Swimlanes to the Process Chart Diagram Note: Some users prefer to keep the Process Chart free of swimlanes, and use the Process Map diagram to show the process flow 'mapped' against swimlanes. Both diagrams offer identical symbols and functionality. Using this technique, you would build (and later view) a Process Chart focusing on how things occur, and build (and later view) a correlating Process Map focusing on who does what. The disadvantage of with this technique is that changes need to be maintained in both diagrams.

At this point we would like to map the process chart we have just created to the parts of the organization in which the events and results occur, or the processes take place. We will draw swimlanes on the diagram, each swimlane representing an organizational unit.

The best way to add swimlanes to an already drawn diagram is to select all of the symbols already drawn, move them down on the diagram workspace, add the swimlanes to the diagram, and then move the symbols into the swimlane in which they occur.

1. From the Edit menu, choose Select All.

2. Left-mouse click on the selected symbols and, holding your mouse button down, drag the symbols down on the diagram workspace as shown below.


6-18

3. Right-mouse-click in whitespace of the diagram workspace,

and select Diagram Properties from the drop-down list.

4. In the Diagram Properties dialog, select Horizontal for the Swim Lanes property and click OK to close the dialog. System Architect will add an unnamed swimlane to the top left of the diagram workspace.

5. Double click on the swimlane symbol or right-mouse-click on it and select Edit. System Architect will present a dialog that says The Symbol Must Be Named to Edit It's Definition. Click OK to close - we will name it.

6. A name dialog opens. Type in Customer and click OK to close the dialog.

Figure 6-9 Select all symbols on diagram and move down.

Adding Swimlanes to the Process Chart Diagram

6-19

Create More Swimlanes for Other Organizational Units

So far we have drawn one swimlane representing the Customer organizational unit. Now let's model other organizational units that are involved with Process Reservation Inquiry.

1. Draw a second swimlane by selecting (and releasing) the Org.Unit tool in the toolbar (two horizontal, parallel lines). This is the tool to draw swimlanes.

2. Left-mouse-click under the first swimlane on the diagram to draw the second swimlane. Name the swimlane Reception.

3. At this point you may want to color the second swimlane differently from the first, to distinguish them from one another. Select the second swimlane symbol, and select Format, Symbol Format, Color.

4. In the Symbol Colors dialog, click on the Colors button within the Fill group. Select a color for this swimlane that is different than the first one drawn, for example light blue. Click OK to close the dialogs.

5. Now let's drag symbols from the drawn diagram into the swimlanes representing the organizational units that they occur in/are performed by.

6. Select the Customer Requests Reservation event and drag it into the Customer swimlane.

Figure 6-10 Select the Org. Unit tool on the Draw menu to draw swimlanes.


6-20

6. Select the Reception swimlane, and drag on its lower

border to widen the swimlane.

7. Select and drag the remainder of the symbols on the diagram into the Reception swimlane.

8. Select File, Save Diagram to save the diagram. Click Ok

to save changes to the diagram.

Figure 6-11 Move event into Customer swimlane.

Figure 6-12 Move other symbols into Reception swimlane.

7-1

7 Relating Roles to Processes

As we model process flows, we need to understand what results on one Process Chart diagram kick off what business events on other Process Chart diagrams. And although we have modeled the organizational units that events, results, and processes occur in, we do not yet have a handle on the specific roles that perform processes (remember an Org Unit generally contains many roles). To model these inter-diagram and inter-definition relationships, we can use System Architect’s Matrix Editor.

In this chapter we will create two matrices, one to relate events to results, and the other to relate Elementary Business Processes to Roles.

Topics in this chapter Page Introduction to Matrices 7-2

The Event to Result Matrix 7-3

View the Results of Event-to-Result Matrix Correlations 7-6

Roles vs Elementary Business Processes 7-7

Relating Roles to EBPs via a Matrix 7-8

Relating Definitions via the Matrix Editor

In this chapter…

Relating Roles to Processes

7-2

Introduction to Matrices System Architect provides a suite of Matrix Editors that can be used to enter information on the models concerning definition correlations and dependencies. From an analysis standpoint, entering data through matrices provides the user with a wide view of the problem domain and the information that the models can/will contain, and the intersections of dependant definitions.

Matrix Editors are provided for all types of modeling in System Architect, including Enterprise business modeling. Users may also create their own.

Synchronized Definitions

Matrices provide another view of the same information contained within symbol definitions. Information entered into the Matrix Editors is automatically entered into the definitions of symbols that appear on diagrams; changes to information in either place are synchronized - the Matrix Editors simply provide another view of the information.

Two Types of Matrices

There are two types of matrices available in System Architect:

• Text Cross-Reference Matrices, which allow text descriptions of the relationship between the two definitions.

• "X in Cell" Cross-Reference Matrices, which allow only an "X" or no "X" in the cross-reference cell between two definitions, denoting whether the two definitions are dependant or not.

The Event to Result Matrix

7-3

The Event to Result Matrix In this section we will establish relationships between results and events that are modeled on the Process Charts in our project encyclopedia.

To open the Event vs. Result matrix:

1. Re-open or re-focus the two Process Chart diagrams Process Reservation Inquiry and Check Customer Credit.

2. In the Windows menu select Tile Horizontally. Both the Process Reservation Inquiry and Check Customer Credit diagrams appear in separate windows. Notice these two diagrams should be linked together because the Result Provisionally Book Room of the Process Reservation Inquiry diagram kicks off the Event Provisionally Book Room in Check Customer Credit. These results and events happen to have the same name, but they don't have to be related.

3. To show this link in the form of a Matrix go to the Tools menu and select Process Modeling Matrices, Process, Business Enterprise, Event to Result. The Specify Filters dialog will appear. This filter will allow you to get a more qualified definition into your matrix. Click Next in order to get the following Choose Matrix Contents dialog to appear.


7-4

4. Click Finish to show all results vs all events in the Matrix Editor. Your diagram should look similar to the following diagram.

Figure 7-1 Choose Matrix Contents dialog.

The Event to Result Matrix

7-5

5. Click in the cell intersecting the Event Provisionally Book

Room with the Result Provisionally Book Room.

6. Click in the cells shown in the diagram above to create other relationships.

Note: An X marks the space where a relationship exists and the space is left blank where one does not exist.

7. Click the X in the right-hand corner of the matrix dialog to save and close the dialog. You will notice a status bar quickly appear and disappear in the upper-left corner of System Architect. This reflects the fact that pertinent definitions have been updated based on information put into the matrix.

Figure 7-2 Event-Result matrix.


7-6

View the Results of Event-to-Result Matrix Correlations To view the results of the correlation formed in the matrix:

1. Return to the Process Reservation Inquiry diagram.

2. Locate and open the definition of the result Provisionally Book Room (by double-clicking on it or right-mouse clicking on it and choosing Edit).

3. On the Related Event tab, notice that the event Provisionally Book Room has been added to the read-only list box of Primary Events.

4. Click OK after viewing the results.

Figure 7-3 Related event is added to Result definition via the matrix.

Roles vs Elementary Business Processes

7-7

Roles vs Elementary Business Processes In the Process Charts, we have established what events and results occur within the organization, and what processes are performed. However, an organizational unit contains multiple roles. We have not yet modeled what specific roles perform what processes. We will use the Elementary Business Process vs. Role matrix to relate processes to roles. (Note: we have already included this encyclopedia with some roles.)

Within the scope of the tutorial map, we are now performing the process highlighted in the picture below:


7-8

Relating Roles to EBPs via a Matrix To open the Elementary Business Process vs. Role matrix:

1. In the Tools menu select Process Modeling Matrices, Process, Business Enterprise, Elem Bus Process to Role. The Specify Filters dialog will appear. This filter will allow you to get a more qualified definition into your matrix. Click Next in order to get the following Choose Matrix Contents dialog to appear.

2. Click Finish to select all the items to be shown in the matrix.

Note: The following diagram contains only a portion of the matrix you have just created.

Figure 7-4 Choose Matrix Contents dialog for Roles to EBPs.

Relating Roles to EBPs via a Matrix

7-9

This is a text-in-cell matrix in which we will be able to relate the processes to roles with a textual description that can describe the constraint of the relationship (for example, a manager may perform a process only if it is a high-priority situation, etc). Typing text into a cell is the same thing as putting an x in it.

3. When finished viewing click the X in the upper right-hand corner of the matrix dialog to close the matrix. You will then be asked if you want to save the matrix.

Figure 7-5 EBPs to Role matrix.

8-1

8 Process Decomposition

A Process Decomposition is a hierarchical, schematic representation of Process Groups, the Process Threads that belong to them, and the Elementary Business Processes contained within a Process Thread.

In the chapter we will create a Process Decomposition diagram, add a Primary Process Group, add Process Threads, and have System Architect automatically add corresponding Elementary Business Processes.

Topics in this chapter Page To Create a New Process Decomposition 8-2

Add a Primary Process Group 8-3

Add Process Threads 8-4

Update a Process Thread with EBPs 8-6

What is Process Decompostion?

In This Chapter…

Process Decomposition

8-2

To Create a New Process Decomposition To create a new Process Decomposition diagram:

1. From the File menu, select New Diagram.

2. Double click on Process Decomposition in the list of diagram types in the Select new type for all Methods dialog.

3. The New Diagram dialog will appear. In the Name box, type Hotel Reservation System.

4. Click the OK button.

Process Decomposition Diagrams

Figure 8-1. The Select New Type for All Methods dialog.

Add a Primary Process Group

8-3

Add a Primary Process Group The Process Decomposition diagram describes logical groupings of Process Threads organized within Primary Process Groups. Note: If a Process Thread has a relationship to another Process Thread in a separate Primary Process Group then the two Primary Process Groups are related.

To add a Primary Process Group to a Process Decomposition diagram:

1. In the Toolbox, find the Primary Process Group symbol, and draw one on the diagram.

2. Name this Group Reservations, and press Enter.

Figure 8-2. Select Primary Process Group symbol from Draw menu.


8-4

Add Process Threads Let's add all of the Process Threads in this project encyclopedia to the diagram, and put them under the Primary Process Group Reservations.

We will use the diagram Choices list box to add all of our Process Threads to the diagram:

1. Right-mouse click on and empty area of the diagram workspace and select Choices. You will get a list box that lists all of the definitions already created that can be drawn on this diagram.

2. Hold down your control key and select all of the Process Threads except for Chelsea Hotels and Resorts Context Diagram in the Select and Drag list box (there should a total of four selected), as shown below. Drag-and-drop them onto the diagram workspace.

3. Drag each process thread symbol directly under the

Reservation Process Group symbol so that they become connected.

Figure 8-3 Drag-and-drop process threads onto diagram workspace.

Add Process Threads

8-5

Note: SA will automatically connect the Process Thread to the Process Group. However, you may have to shift the Process Thread around to ensure it is in the correct position.

Figure 8-4 Build hierarchy.


8-6

Update a Process Thread with EBPs To automatically add the Elementary Business Processes to each Process Thread:

1. Hold down the shift key on your keyboard and select each of the Process Threads on the diagram (all four process threads should be selected).

2. Select Dictionary, Update Selected Process Threads EBP's. A dialog will appear asking to Update Process Threads with Business Elementary Processes? Click OK.

3. System Architect will automatically add the Elementary Business Processes from the list of corresponding Process Thread definitions in your browser.

Figure 8-5 Automatically update process threads with elementary business processes that belong to them.

9-1

9 Building a Functional Hierarchy

A Function is an occurrence that triggers a business to commence a process. A Functional Hierarchy diagram represents the functions in the chosen diagram and any related child diagrams. (There is no practical limit to the number of levels that can be represented.)

In this chapter we will take stock of the functions that Chelsea Hotels and Resorts performs, and map these functions to the processes used to perform them. We will then build a Functional Hierarchy diagram, which will give us a nice summary of every function, and the processes performed to achieve it.

Topics in this chapter Page Examine the Functions of the Business 9-2 Relate Business Processes to Functions 9-3 Create a Functional Hierarchy 9-5

What is a Functional Hierarchy?

In this section…

Building a Functional Hierarchy

9-2

Examine the Functions of the Business As mentioned earlier, a function is something that an organization does. This is distinguished from a process, which is how an organization performs a function. In a hotel chain, functions are maintenance of the hotels themselves (including building maintenance, gardening, etc), human resources, marketing, reservations, etc. Sometimes a division or a department (in general terms an organizational unit) will perform a function by itself (i.e., the human resources department performs the human resources function). Oftentimes, however, multiple departments will combine to perform a function. In this chapter we will take stock of the functions that Chelsea Hotels and Resorts performs, and map these functions to the processes used to perform them. Within the scenario for this tutorial, we will perform the processes in the picture below.

Relate Business Processes to Functions

9-3

Relate Business Processes to Functions Our project encyclopedia is prepopulated with a number of functions - Perform Building Maintenance, Perform Marketing, Reserve and Book Rooms, Perform Sales Activity, Provide Accounting Services, etc. Let's now relate some of these functions to the processes that perform them. We will use the Elementary Business Process (EBP) to Function matrix. To open the EBP to Function matrix:

1. In the Tools menu find and select Process Modeling Matrices, Process, Business Enterprise, Elem Bus Process to Function. The Specify Filters dialog will appear. This filter will allow you to get a more qualified definition into your matrix. Click Next in order to get the following Choose Matrix Contents dialog to appear:

2. Click Finish to select all items to be shown in the Matrix.

Figure 9-1 Mapping business processes to functions via a matrix.


9-4

3. Note that there are a number of correlations between functions and processes already made. Let's make a couple more. Add an x mark in the cell intersecting the functions and processes listed below.

• "Perform Marketing" Function to the Elementary Business Process "Store Customer Details".

• "Perform Marketing" Function to the Elementary Business Process "Store Marketing Info in Database".

• "Reserve and Book Rooms" Function to the Elementary Business Process "Check Room Availability".

• "Reserve and Book Rooms" Function to the Elementary Business Process "Reserve Room".

4. Click on the X in the upper right-hand corner of the matrix dialog to close the Matrix. You will then be asked to save the matrix.

Figure 9-2 EBP to Function matrix.

Create a Functional Hierarchy

9-5

Create a Functional Hierarchy Let's now create a Functional Hierarchy diagram for Chelsea Hotels and Resorts:

1. From the File menu, select New Diagram.

2. Double click on Functional Hierarchy from the list of diagram types in the Select new type for All Methods dialog.

3. In the New Diagram dialog, type in Chelsea Hotels and Resorts as the name and click OK.

4. From the toolbox or Draw menu, select the Org. Function tool and place a new function symbol on the diagram. Name it Chelsea Hotels and Resorts.

5. In the browse, click on + sign next to Definitions to reveal the drop-down list.

6. Find and click the + next to Functions to reveal the function list.

7. Select the first function, Maintain Office Administration, and, holding down your shift key, select the last function, Reserve and Book Rooms, so that all functions are selected in the browser.

8. Hold down your left mouse button and drag all of the functions listed in the browser onto the diagram workspace.


9-6

9. Select each function and drag it directly under the main function Chelsea Hotels and Resorts, until it automatically attaches, then release.

10. Select all the functions on the diagram by holding down the shift key and selecting each function (or do a Windows 'lasso').

11. With each function selected, go to the Dictionary menu and select Update Selected Functions EBP's. Each function updates its Elementary Business Processes as shown in the following diagram.

Figure 9-3 Drag functions onto diagram workspace.

Figure 9-4 Build functional hierarchy.

Create a Functional Hierarchy

9-7

This is the end of the tutorial for business modeling with System Architect. We have only covered a small portion of the business modeling available. For more information, please review the on-line help.

Figure 9-5 Open the Business Profile definition for Chelsea Hotels and Resorts.

10-1

10 Introduction to UML

The Unified Modeling Language (UML) has become the standard notation for modeling object-oriented and component-based systems. UML is a language not a method – it provides a specification for a standard set of symbols to represent object-oriented systems and concepts, and a specification for the underlying semantics – clearly defining what the symbols mean and how they are related. It is not a method because it does not specify how to build systems.

This chapter provides the background information about the UML and the object modeling.

Topics in this chapter Page

Object-Oriented Modeling 10-2

This Tutorial -- A Use Case-Driven Approach 10-3

Opening the Tutorial Encyclopedia 10-6

Setting Preferences 10-9

Explanation of Some Preferences 10-10

In this Chapter…

Introduction to UML

10-2

Object-Oriented Modeling Object-oriented modeling can be divided into two schools: data-centric design and problem-centric design. Data-centric designers use the Class diagram as the focal point in developing the system. Problem-centric designers focus on modeling how the system solves the problem at hand, using diagrams such as the Use Case diagram and the Sequence/Collaboration diagram.

The data-driven approach involves beginning analysis with the UML Class diagram, the main static analysis diagram which shows relationships between classes in the system.

The problem driven approach involves beginning analysis by trying to capture the problem at hand. This approach uses Use Case and/or Sequence and Collaboration diagrams to model the scenarios in the existing system or in the system to be built.

Modelers using the problem driven approach put the classes discovered in their scenarios through a rigorous analysis to determine the classes responsibilities in the system and what other classes they collaborate with to fulfill those responsibilities. Class Responsibility and Collaborator (CRC) cards are a helpful technique for this kind of analysis.

Data-driven Approach

Problem/Responsibility-Driven Approach

This Tutorial -- A Use Case-Driven Approach

10-3

This Tutorial -- A Use Case-Driven Approach There are many methods for developing object-oriented and component-based systems. In this tutorial, we will follow a Use Case-driven approach. We will begin analysis with Use Cases, take you through the steps of modeling with Sequence and Collaboration diagrams, and then build a simple UML Class diagram.

Below is a review of the basic technique involved with a Use Case-driven approach.

Before beginning to model, you want to understand the scope of your project. For example, will you be modeling your entire business, or only certain systems within the business. With UML, you may use packages to subdivide your models. You can create packages for each of the systems you are modeling, for example, Reservations, Human Resources, etc. You may also create packages for each stage of development, for example, Business Analysis, Logical Analysis, and Deployment.

The Use Case technique captures information about how a system or business currently works or how you wish it to work. Although not a true object-oriented approach, the Use Case technique helps you build scenarios which model the processes of the system. It is an excellent way to lead into object-oriented analysis of systems.

Typically, Use Case diagrams are modeled for every scenario in the system or business. Each Use Case can be defined simply with text describing the scenario. You may also define the scenario with the sequence of steps performed within it or with the conditions that exist before the scenario begins or after it completes.

An actor is considered an external agent to a system: someone or something that requests a service from the system or acts as a catalyst for something in the system to occur. UML specifies that the actor is a class of objects, not a particular instance of a class (or object). The actor is represented as a class with a stereotype of actor.

A Sequence or Collaboration diagram is modeled for every scenario in the system. Whereas the Use Case diagram models a business view of the scenario, the Sequence diagram contains implementation details of the scenario, including the objects and classes used to implement the scenario and the messages passed between the objects.

Define the Scope

Begin with business analysis and Use Cases

A Use Case for every Scenario

Actors as external agents

Migrate from Use Cases to Sequence/Collaboration diagrams

Introduction to UML

10-4

Typically one examines the description of the Use Case to determine what objects are necessary to implement the scenario. If you have modeled the description of the Use Case as a sequence of steps, then you can 'walk through' the steps to discover what objects are necessary for the steps to occur.

The Sequence diagram uses vertical lines to represent objects and horizontal vectors to represent messages passed between the objects. At first, you may want to label the message lines in the Sequence diagram with the business name of the message, similar to the Use Case step. As your design progresses, you may want to label the message lines with the name of a method that one object is asking the other to invoke.

The Collaboration diagram represents an alternate view of the Sequence diagram. The Collaboration diagram shows how the objects in the scenario interrelate, giving the modeler the ability to show detail, such as visibility. Collaboration diagrams are good for understanding all of the effects on a given object and are good for procedural design.

The class diagram is the main static analysis diagram for a system. It specifies the class structure of the system with relationships between classes and inheritance structures.

In a problem-driven approach to OO analysis, the class diagram is developed through information garnered from the Use Cases, the Sequence diagrams, and the Collaboration diagrams. The objects found during problem-driven analysis lead the user to model the classes they instantiate. The links among objects provide a map to modeling the relationships among their classes. Collaboration diagrams provide the most useful information, in that they show interactions among objects to solve a particular problem.

The class diagram is developed in an iterative fashion, through a repeated cycle of analysis, design, and implementation. This process is referred to as 'round-trip engineering'.

Often issues that affect the design arise during implementation. Changes made to implementation code need to be reversed back into the analysis model so that iterative design can continue. System Architect facilitates this process by enabling you to implement the design in Java, C++, or Visual Basic and then reverse that code back into the existing class diagram, automatically updating the information stored on the diagram and in the underlying encyclopedia.

UML Sequence diagram

UML Collaboration diagram

UML Class diagram

Iterative design

This Tutorial -- A Use Case-Driven Approach

10-5

Whereas Interaction and Collaboration diagrams model dynamic sequences of action among groups of objects in a system, the State diagram models the dynamic behavior of a particular object or class of objects.

A State diagram is modeled for all classes deemed to have significant dynamic behavior. This type of diagram models the sequence of states an object of a class goes through during its life. The State diagram captures the object's received stimuli, responses, and actions.

For example, the State diagram models an object's behavior in terms of what state it is in initially and what state it transitions to when a particular event is received. It also models what actions an object performs while in a certain state.

Use the Component diagram to model the structure of the software, including dependencies among software components, binary code components, and executable components.

The Component diagram is drawn as a graph of components, sometimes grouped in a package, and the dependencies that exist between components (and packages of components).

Use the Deployment diagram to model the configuration of run-time processing elements and the software components, processes, and objects that live on them.

In the Deployment diagram, you model the physical nodes and the communication associations that exist between them. Each node can contain run-time component instances, indicating that the component lives or runs on the node. You can also model the objects that are contained within the component.

Model class behavior with a UML State Diagram

Model component behavior

Model distribution and implementation

Introduction to UML

10-6

Opening the Tutorial Encyclopedia The following steps on opening an encyclopedia and setting preferences are only presented for users who are taking this UML portion of the tutorial first. If you've already performed the Business Modeling section of this tutorial, and have the Tutorial encyclopedia open, you do not have to perform the following steps.

We will open an encyclopedia that has already been populated with some of the systems we will build. The project encyclopedia we will open for is called TUTORIAL.

Important Note: In this tutorial, we will model in the encyclopedia provided called Tutorial, using information already provided in it as a starting point. If other team members have already taken this tutorial and modified the Tutorial encyclopedia, you may want to start with a fresh version of this encyclopedia as a starting point. A zip file, Tutorial.zip, is provided in the Tutorial directory. It provides a fresh version of the Tutorial encyclopedia. You should unzip this file to a new path before beginning these exercises.

To open the TUTORIAL encyclopedia with System Architect:

1. From the File menu, select Open Encyclopedia.

Creating/ Opening an Encyclopedia

Figure 10-1 Open encyclopedia.

Opening the Tutorial Encyclopedia

10-7

The Encyclopedia Open dialog appears. The Samples encyclopedia within the Existing tab is selected by default.

2. Choose a project by selecting the Browse button on the Existing tab to reveal all of the project encyclopedias in this folder. Select the Tutorial encyclopedia and choose OK.

3. If not already selected, toggle on Load this project at

startup, located at the bottom left of the open a project dialog. This will make this encyclopedia the default encyclopedia that will automatically open each time you start the product.

4. Click OK to load the project.

Next, let's take a look at the Property Configuration dialog box to see what methods, diagram types, and target languages are selected for this project encyclopedia. These can be changed at any time during the project.

Figure 10-2 Open the Tutorial encyclopedia.

Property Configuration

Introduction to UML

10-8

Select Tools, Customize Method Support, Encyclopedia Configuration to open the System Architect Property Configuration dialog. You will notice that the encyclopedia has been configured for Entity Relation Data Modeling, Enterprise Business Modeling, and UML, among other things. We have chosen Oracle as the Target Database and Java as the Target Language as shown below.

Note: You can change the Property Configuration at any time using the Customize Method Support, Encyclopedia Configuration command from the Tools menu. After making changes you must reopen the encyclopedia for the changes to take effect.

Figure 10-3 Specify methods and properties to use.

Setting Preferences

10-9

Setting Preferences Now you are almost ready to begin the tutorial project. However, first you need to set your preferences for how System Architect will react to your drawing commands.

System Architect offers many optional drawing and tool behavior features. They can be turned on or off at any time with the Preferences dialog.

To set preferences:

1. From the Tools menu, select Preferences. The Preferences dialog opens.

2. Within the Auto grouping, toggle on Number, as displayed below.

3. Click OK to close the Preferences dialog.

Figure 10-4 Set drawing and behavioral preferences.

Introduction to UML

10-10

Explanation of Some Preferences Here are explanations for some of the major settings chosen in the picture on the previous page:

For a fuller explanation of the Preferences dialog, go to the Help menu and select Help for the On-line Help System. You can also find this information in your System Architect User Guide or System Architect Tutorial manual, as well.

11-1

11

Modeling With UML Use Cases

Use Case modeling captures information about how a system or business currently works or should work. With the Use Case technique, you model and describe all scenarios of the business or its systems, and who interacts with each scenario. This is more process modeling than object-oriented, but it is a proven way to begin understanding what the objects are in the system.

In this chapter we will model part of the hotel’s reservation system with UML Use Case diagrams.

Topics in this chapter Page How to Model with Use Cases -- Discussion 11-2 Organize the Project with Packages 11-4 Modeling Use Case Scenarios 11-7 Create a Child UML Use Case Diagram 11-12 Defining the Actors 11-15 Define a Use Case with Steps 11-16 Create an Includes Relationship 11-20 Extend a Use Case 11-21 Tracking Requirements Against Use Cases 11-23

Introduction

In this Chapter…


11-2

How to Model with Use Cases -- Discussion In this section we will begin using Use Cases to model the business scenarios. Within the scenario map for this tutorial, we will perform the process highlighted in bold in the picture below.

On a Use Case diagram, you model Use Cases, representing the scenarios in the business or system, and the external actors which interact with the scenarios, helping you capture the way a system or business works or should work. The scenarios are described with text or with a sequence of steps. Use Case modeling is considered a problem-driven approach to object-oriented analysis because the designer gives primary consideration to the problem at hand and not to the relationship between objects (as in the data-driven approach).

Modeling with Use Cases can illuminate the need for objects in your system. Once the system has been described in terms of its scenarios, the modeler can examine the text or the steps defining each scenario and determine necessary objects.

When building a new system, designers model scenarios which describe the way the system or business should work. When redesigning an existing system, many modelers choose to model first the scenarios of the current system and then the scenarios for how the system should work.

How to Model with Use Cases -- Discussion

11-3

Use Cases are also used in testing a design. Once the design is complete, the modeler can walk through the steps of the scenarios to determine if the design enables the scenarios to occur as planned. Where do Use Cases fit in with the process and functional modeling that we have done so far in this tutorial? They differ in approach: If a user is strictly using UML to model their business and systems, they may use Use Cases at the very start of contextual modeling, creating a Context Use Case diagram that divides the segments of the business with packages, and create Use Cases for each business segment package. UML Activity diagrams might then be used to model the process flow of each business Use Case.

Other users prefer to use the techniques presented in this tutorial so far - using process chart diagrams to get a handle on the business events, process flows, and results, and the functions that these processes create for contextual and conceptual business modeling. Once these diagrams have been created, the user has the option of using Use Cases as a bridge into object-oriented analysis and design of the business systems. You might create a Use Case corresponding to every low-level process (Elementary Business Process) on the Process Chart diagram, then use the techniques of UML to examine the Use Cases to find objects. Although this introduces a second set of diagrams representing similar ideas (and thus added modeling maintenance, since a change to a business process would have to be represented in both places), it can provide a clear bridge between conceptual business modeling and system modeling with UML.

A third alternative would be to skip UML Use Cases entirely, and use the Process Charts to drive the next levels of application design (i.e., creating Sequence and Class diagrams).

Use Cases vs Process Models


11-4

Organize the Project with Packages As we start our business modeling with Use Cases, the first thing we want to do is define the scope of our project. We can categorize the parts of the business we will model using packages. For example, in a hotel business, the Use Cases involved with making a reservation should not be mixed with those involved with paying the employees, which should not be mixed with those involved in maintaining the hotel. Instead, you might categorize them as separate packages: Reservations, Human Resources, and Building Maintenance.

In addition, we may want to categorize our project in terms of the stages of development. For example, we may want to create packages for the Business Use Case View, the Logical View, the Physical Component View, and the Physical Deployment View. In modeling this way, we can create business elements that are separate than logical elements that are separate from design elements -- for example, a Customer class in the Business Use Case View will be a different class than a Customer class in the Logical View.

For this Tutorial we'll subdivide our project into packages for various stages of development -- we'll create a Business Use Case View, a Logical View, a Physical Component View, and a Physical Deployment View. Within the Business Use Case View, we'll build a Reservations package to hold the Use Cases of that system.

Let's create a Business Use Case View package:

1. Select the UML tab in the browser. Right-mouse click on the Packages folder and select New. The Select new type for UML dialog will open.

Create a Business Use Case View Package

Organize the Project with Packages

11-5

2. Double click on the Packages folder to create a new

package. The Dictionary Object - Package dialog will open.

3. Type in the name of the new package, Business Use Case View. Click OK. Another Dictionary Object - Package dialog will open, this time enabling you to specify the parent package.

4. Since we want to create this package at the highest level, we'll leave the Parent Package - (Package) field empty (the Packages folder that it will fall under doesn't count). Click OK to close the second dialog. The new package will be created, and will be placed in alphabetical order under the Packages folder.

Figure 11-1 Create new package.


11-6

Let's now further refine what part of the business we will model with Use Cases.

5. Right-mouse click on the Business Use Case View folder and select New. The Select new type for UML dialog will open.

6. Double click on the Packages folder to create a new package. The Dictionary Object - Package dialog will open.

7. Type in the name of the new package, Reservations. Click OK. Another Dictionary Object - Package dialog will open, this time enabling you to specify the parent package.

8. Click on the Choices button next to the Parent Package - (Package). From the list of packages provided, select Business Use Case View, and holding down your left mouse button, drag-and-drop it into the Parent Package field. Click OK to close the dialog.

Figure 11-2 New package added to browser.

Modeling Use Case Scenarios

11-7

Modeling Use Case Scenarios Creating the Context Use Case Diagram During business analysis of the system, you can develop one Use Case diagram that acts as the context Use Case diagram. On this diagram, you can draw the overall Use Cases of the domain, with actor interactions. One of the goals of drawing a Context Use Case diagram is to identify all of the actors of the system. You may optionally use the System symbol to further refine the categorization of the Use Cases.

1. In the UML tab of the browser, right-mouse click on the package Reservations and select New. The Select new type for UML dialog opens.

2. Double-click on Use Case (under the list of Diagrams). The New Diagram dialog opens.

3. Type in the name of the new Use Case diagram, Reservations Context Diagram. Click OK. In the next dialog that opens (titled Diagram - Use Case - Reservations Context Diagram), you may specify the package that this diagram will be contained in. It is automatically filled in with the name of the package you right-mouse clicked on (Reservations). You can specify a different package at this point, but we'll leave it Reservations.

The first goal of modeling scenarios is to determine how an external actor uses the system to gain something from it and what scenarios the actor can go through. When making a reservation, it is an external actor called Customer who can make a reservation.

4. From the Draw toolbar, select the Actor symbol. (The Actor symbol is a stereotype of a class -- it is located under the Class symbol. Click on the down button next to the Class symbol and select the Actor symbol. It resembles a stick figure.) Your cursor turns into a drawing pen.

Create a Use Case Diagram

Modeling an Actor


11-8

5. Left-mouse click once on the diagram workspace to draw

the actor. Name the actor Customer, and hit Enter.

The Customer can make a reservation. Let's draw a Use Case called Make Reservation.

6. Select the Use Case symbol on the toolbar (looks like an oval) and release your mouse. Your cursor will turn into a drawing pencil. Left-mouse click on the diagram workspace to draw a Use Case symbol on the diagram. Name the Use Case Make Reservation.

During Use Case analysis, the Use Case Association line is used to show simple communication between an actor and a Use Case.

7. From the toolbar, select the Use Case Association line drawing too. Your cursor will turn into a drawing pencil.

8. Draw an association between the Customer actor and the Make Reservation Use Case as follows: Place the drawing cursor inside the Customer actor and click once (and release) so that you get a + connector indicator. Move your line over to the Make Reservation Use Case to get a + connector indicator. Once you get a + indicator at both ends of the Use Case Association line, left click your mouse again to make the connection.

Figure 11-3 Select the actor symbol.

Modeling a Use Case


11-9

You may want to widen the Use Case at this point to fit the name better.

9. Select the Use Case and drag on its right center handlebar to widen it.

To set this width as the default for all future Use Cases drawn, select the Use Case and choose Format, Symbol Format, Symbol Style. In the Symbol Style dialog that opens, toggle on Set Size and click OK. One other actor communicates with this Use Case - Reception. Now reception may be a person, or it may be the company's website. If there is a difference between the two, we might model them as two different actors, but for now we will model it as one actor - Reception.

10. From the Draw toolbar, select the Actor symbol. Place the actor symbol on the diagram to the right of the Make Reservation Use Case, name it Reception, and hit Enter.

11. From the toolbar, select the Use Case Association line drawing tool and draw a Use Case Association line from the actor Reception to the Use Case Make Reservation.

Figure 11-4 Connect actor and Use Case with Use Case association.

Figure 11-5 Select Use Case and drag handlebar to widen.


11-10

A customer also interacts with our reservation by confirming a reservation, cancelling a reservation, and reserving a conference room. In addition, reception may check-in a guest or check-out a guest. Let's model these scenarios as Use Cases:

12. Draw the following Use Cases, under Make Reservation:

• Confirm Reservation

• Cancel Reservation

• Check In Guest

• Check Out Guest

• Reserve Conference Room

13. Connect the Customer actor to each Use Case with a Use Case Association line, and connect the Reception actor to each Use Case with a Use Case Association line to create the diagram below:

Figure 11-6 Add Reception actor


11-11

This is a first level of Use Cases for our Hotel Reservation System. We are not trying to get into too much detail here, just establish the main scenarios involved with reserving rooms. The Use Cases on this diagram are similar to the Process Threads we established in the previous section on Business Modeling.

Figure 11-7 Use Case context diagram.


11-12

Create a Child UML Use Case Diagram Now let's model the Make Reservations Use Case in greater detail. We'll create a child Use Case diagram:

1. Right-mouse click on the Make Reservations Use Case and select Child Create from the drop-down menu. The Child Create dialog opens.

2. Leave the default selections to create a Use Case diagram

named Make Reservations, and click OK to close the Child Create dialog. You will receive a message asking you if you'd like to save changes to the Use Case diagram that had been open.

3. Click Yes to save changes to Reservations Context Diagram.

Figure 11-8 Right-mouse click on Use Case and choose Child Create.

Create a Child UML Use Case Diagram

11-13

Drawing the Child Use Case Diagram

We have already modeled part of the Make Reservation Use Case scenario on the Use Case Context diagram. Let's reuse that information. First let's redraw the Make Reservation Use Case that was already included on the Use Case Context diagram.

1. Select the Select Mode pointer tool from the toolbar, then right-mouse click anywhere on the white area on the Use Case diagram workspace and select Choices from the drop-down list. The Select and Drag dialog gives you a list of all modeling elements that already exist in this encyclopedia that can be reused on this diagram.

2. At the bottom of the Select and Drag dialog, find the Use Case Make Reservation. Select and drag it onto the diagram workspace.

3. At the top of the Select and Drag dialog, find the class labeled Customer.Reservations (this is the class name and the package name separated by a period). Select and drag it onto the diagram workspace to the left of the Make Reservations Use Case. Notice that the Use Case Association is automatically drawn between them.

4. In the Select and Drag dialog, find the class Reception.Reservations, and select and drag it onto the diagram workspace to the right of the Make Reservations Use Case. The Association is drawn automatically between them.


11-14

5. Click the x in the upper-right-hand corner of the Select and Drag dialog to close it.

Figure 11-9 Draw actors and Use Case on child diagram.

Defining the Actors

11-15

Defining the Actors The Customer and Reception actors are considered to be classes of objects with a stereotype of actor. If you open up an actor's definition dialog, you will see a definition dialog for a class, with Stereotype property filled in for Actor. Although we could add details to the definitions of the actors we have drawn at this point, such as attributes, we will not. We will add information about classes when we take a closer look at the behavior of these classes (and their instances, or objects) with Sequence diagrams in the next section. Defining a Class: You do not normally need to detail any information about the class at this stage of development. In fact, during early, business-level analysis of the system you may want to purposely avoid spending any time adding details so that you do not get sidetracked from the important thing at hand - modeling the dynamics of the scenario. Later, you may go back to the class definition and add details. In this tutorial in fact, we will create a new logical, Customer class in a later section.


11-16

Define a Use Case with Steps The simplest way to define a Use Case is by writing a textual description of the scenario. There are other ways to define the Use Case, for example, listing the steps that form the scenario. In addition, one may want to list the pre-conditions that must exist before the scenario can take place and the post-conditions that must exist after the scenario has run its course. Let's start with some basic steps for Making a Reservation, assuming the room the customer requests is available and the customer's credit is good:

1. Customer Queries for Available Rooms

2. Store Customer Details

3. Check Diary for Room Availability

4. Room is Available

5. Advise Customer of Availability

6. Customer Requests Reservation

7. Provisionally Book Room

8. Figure Out Price; Advise Customer

9. Customer Accepts Terms

10. Check Customer Credit

11. Customer Credit OK

12. Reserve Room

To add these steps to the definition of the Make Reservation Use Case:

1. Open the definition dialog of the Make Reservation Use Case by double-clicking on it or right-mouse-clicking on it and selecting Edit.

2. Select the Steps tab within the Use Case definition. You will see a grid for Use Case Steps.

Define a Use Case with Steps

11-17

3. Put your cursor in the Name column of the first row of the

Use Cases Steps grid, and type in the first step: Customer Queries for Available Rooms. Hit your Enter key to add it to the grid.

4. Add the remaining 11 Use Case Step listed at the start of

this section, hitting your Enter key after typing in each one to add it to the grid.

Figure 11-10 Type in steps of Use Case in grid.

Figure 11-11 Add step to Use Case.


11-18

Figure 11-12 Complete set of steps added to Use Case.

Define a Use Case with Steps

11-19

You may specify a textual description of each step. You may type the Step Text directly into the grid, in the cell next to the step you wish to describe, or place your cursor in the step's Name box and click on Define to open the full definition of the step, and type the text in the Step Text field.

5. In the Step Text column, in the row for Customer Queries for Available Rooms, add the Step Text: Customer queries for room availability on certain dates.

Note that if you place your cursor at the column borders at the head of the grid, you can increase or decrease the widths of each column.

Define a Step

Figure 11-13 Add step text.


11-20

Create an Includes Relationship Between Use Cases When modeling Use Cases, you will model a separate Use Case for every unique scenario. There will be certain sub-scenarios that will occur over and over again within Use Cases of your system. Instead of describing each sub-scenario over and over again, you can describe it once, in a separate Use Case, and have other Use Cases "Include" this Use Case.

Within our system, the sub-scenario of Checking a Customer's Credit is an ideal candidate to be pulled into its own Use Case.

1. Select the Use Case symbol on the toolbar and draw a new Use Case symbol on the diagram named Check Customer Credit. Place it above and to the right of Make Reservation.

2. From the toolbar, select the Includes line drawing tool and draw an Includes line from the Use Case Make Reservation to the Use Case Check Customer Credit. You do not need to name the line, simply hit your Enter key (or left mouse click) to draw the line unnamed. Once drawn, you may adjust the positioning of the <<include>> stereotype on the line.

Figure 11-14 Create <<include>> relationship.

Extend a Use Case

11-21

Extend a Use Case When modeling Use Cases, there will often be alternative courses of action that we want to model. For example, for the Use Case Make Reservation, we assume that the customer's credit is good. If it is no good, the steps of the Use Case will be identical up until the step of checking the customer's credit, after which the steps will be different. We can model all of this behavior in one Use Case or we can simply extend the Use Case Make Reservation with another Use Case, called say, Reservation Denied Because of Bad Credit.

1. From the Draw toolbar, select the oval Use Case symbol. Place a Use Case symbol on the diagram underneath Make Reservation, name it Reservation Denied Because of Bad Credit, and hit Enter.

2. From the Draw toolbar, select the Extends line drawing tool and draw an Extends line from the Use Case Reservation Denied Because of Bad Credit to the Use Case Make Reservation. You do not need to name the line. Once drawn, the <<extend>> stereotype shows on the line.

Figure 11-15 Create <<extend>> relationship.


11-22

Open the definition of the extends line between Reservation Denied Because of Bad Credit and Make Reservation (double-click on the line or right-mouse click on it and select Edit).

1. For the Extension Point property, click on the Choices button to get a list of steps of the extended Use Case.

2. Drag-and-drop the step Check Customer Credit into the Extension Point field.

General Use Case theory recommends that at least one Use Case be prepared for each significantly different kind of scenario instance. Each scenario shows a different sequence of interactions between actors and the system, with all decisions definite.

When you have arrived at the lowest Use Case level, you can create a child Sequence diagram (and accompanying Collaboration diagram) for the Use Case. With these Sequence and Collaboration diagrams, you can model the implementation of the scenario.

Specify the Extension Point

Figure 11-16 Specify extension point.

When to Stop Decomposing Use Cases

Tracking Requirements Against Use Cases

11-23

Tracking Requirements Against Use Cases Use Cases serve a dual purpose on the requirements level - they can be used to help you find or establish your requirements, or, if you already have set requirements for your system, you can attach those requirements to your Use Cases so that you know your designed models meet your requirements.

In the Business Modeling section of this tutorial, we created a number of business requirements and entered them into System Architect. In this section, we will attach them to the Use Case which describes the part of the system that satisfies those requirements.

1. Open the definition of the Use Case Make Reservation (double-click on it or right-mouse click and select Edit).

2. Select the Requirements tab. This tab and the properties within it were added to the Use Case definition through System Architect's extensibility mechanism - USRPROPS.TXT.

3. In the Related Requirements list box, click on Choices in the bottom right-hand corner. The Select and Drag dialog displays all of the business requirements that you entered in the business modeling section of this tutorial.

4. Right-mouse click in the Select and Drag dialog and select Details from the drop down list to view a summary box at the bottom of the dialog.

The requirement Retrieve Credit Information From Consumers is satisfied by this Use Case.

5. Select the requirement Retrieve Credit Information From Consumers in the Select and Drag dialog. Drag and drop it into the Requirements list box. Close the Select and Drag dialog.


11-24

6. Select the requirement Retrieve Credit Information From Consumers and click Define at the bottom of the Related Requirements list box to open the requirement's definition dialog.

7. Notice within the requirement's definition there is a tab for

Related Requirements and Process. Within this tab you can see a list box for related Business Objectives.

Through these dialogs we can see the requirements traceability; we see why the Use Case exits -- what requirements it satisfies, and for each requirement we see why it exists -- what high-level business objectives it satisfies.

8. Click OK to close the dialog.

Requirements Traceability

12-1

12 UML Sequence and Collaboration Diagrams

Whereas you use Use Cases to gain a high-level business view of what goes on in the system, with the Sequence diagram you detail the interactions among objects in the system. The Collaboration diagram offers a different view of the same information as the Sequence diagram. The two are sometimes refered to as Interaction diagrams.

In this chapter’s exercises you will use UML Sequence and Collaboration diagrams to model object interactions within scenarios.

Topics in this chapter Page Sequence and Collaboration Diagrams 12- 2 Create Sequence/Collaboration Diagrams 12- 4 Create a Sequence Diagram 12- 6

Create Collaboration Diagram 12-23

Synchronize Sequence Diagram 12-27

Introduction

In this Chapter…

UML Sequence and Collaboration Diagrams

12-2

Sequence and Collaboration Diagrams Whereas you use Use Cases to gain a high-level business view of what goes on in the system, with the Sequence diagram you detail the interactions among objects in the system. The Collaboration diagram offers a different view of the same information as the Sequence diagram. The two are sometimes referred to as Interaction diagrams. Within the Process Chart that we are using to navigate this tutorial, we are at the following place, highlighted in bold in the picture below:

Like Use Case diagrams, you use Sequence diagrams to model scenarios in the system. They offer a different level of detail, however. Whereas Use Cases and the steps or textual descriptions that define them offer a high-level-analysis view of a system, the Sequence diagram offers more specific analysis and design information about the interactions among objects in the system. In a Sequence diagram, an object appears on the diagram as a vertical dashed line, often referred to as an object lifeline. A rectangular box at the top of the object lifeline contains the name of the object, with its class name optionally listed after it, separated by a colon. Messages or Stimuli appear as horizontal lines between

Sequence Diagram

Sequence and Collaboration Diagrams

12-3

objects. Message/Stimuli lines are drawn in chronological order, from the top of the diagram to the bottom. They do not necessarily have a one-to-one correspondence with the steps defined for a Use Case scenario.

The Collaboration diagram shows how the objects in a scenario interrelate. In a Collaboration diagram, the modeler can show detail such as visibility.

Each object in a Collaboration diagram instantiates a particular class in the system. The objects are connected by links, each link representing an instance of an association between the respective classes. The link shows messages sent between the objects, and the type of message passed (synchronous, asynchronous, simple, balking, and timeout).

For the modeler trying to understand all of the effects on a given object, Collaboration diagrams offer a better view of a scenario than a Sequence diagram. Collaboration diagrams are therefore good for procedural design.

To show the implementation details of a scenario, you can choose to draw either a Sequence or a Collaboration diagram, or both. System Architect automatically creates a Collaboration diagram from a Sequence diagram, and vice versa, when you invoke the Synchronize Diagram command from the Draw menu.

Collaboration Diagram

Keeping the Diagrams in Synch


12-4

Create Sequence/ Collaboration Diagrams In this section of the tutorial, we will create a Sequence diagram. In UML, you model a Sequence and (optionally) a Collaboration diagram for every scenario in the system.

Our first task is to find the objects, classes, and messages of the system. To do this, we'll examine the description of the Use Case. If you have modeled the description of the Use Case as a sequence of steps (as we have done in this tutorial), then you can ‘walk through’ the steps to discover what objects are necessary for the steps to occur.

Sequence/ Collaboration Diagrams

Create Sequence/ Collaboration Diagrams

12-5

Finding Objects By Examining Use Case Scenarios

The Use Case technique has become a popular vehicle for finding objects during an object-oriented analysis of a system. After modeling the scenarios for the way a system works or should work, you can then examine those scenarios to find the objects necessary for the scenarios to take place.

One way to find objects is to examine the textual description or steps of every Use Case. Consider nouns in the textual description to be classes or class attributes and verbs to be methods of the classes.

For example, in the Make Reservation Use Case, in order for a Customer to request a reservation, two objects are necessary: Customer and Reception. In order for the step Check Diary for Room Availability to occur, the objects Room and Diary must exist. In order for the step Customer accepts accommodation to occur, the objects Customer and Room must exist, etc. Looking at the steps of Make Reservation, we highlight possible objects in bold, possible class attributes in bold underline, and possible methods in italic.

1. Customer Queries for Available Rooms

2. Store Customer Details

3. Check Diary for Room Availability

4. Room is Available

5. Advise Customer of Availability

6. Customer Requests Reservation


8. Figure Out Price, Advise Customer

9. Customer Accepts Terms


11. Check Customer Credit

12. Customer Credit Is OK

13. Reserve Room

Examine Nouns and Verbs


12-6

Create a Sequence Diagram Let's model this scenario with a Sequence diagram. We will create a Sequence diagram, and make it a child of the Use Case diagram we created in the earlier section. This will create a hypertext link between the two diagrams. For this tutorial, our Use Cases were in the Business Use Case View package. We will build our Sequence diagrams in a Reservation System package within the Logical View package. To create a Sequence diagram:

1. In the UML tab of the browser, click on the + mark next to the Logical View package to expand it, revealing the Reservation System package underneath it.

2. Right-mouse click on the Reservation System package and select New to open the Select New Type for UML dialog.

3. Within the Diagrams list, double-click on Sequence to create a new Sequence diagram.

4. Type in Make Reservation in the New Diagram dialog.

In a Sequence Diagram, an object is shown as a long, vertical, dashed line. This is considered the object lifeline. It represents the life of an object during a scenario. We discovered above that the objects Customer, Reservation, Room, and Diary are needed for the Make Reservation scenario. Let's model them.

1. Select the object symbol from the toolbar and place an object symbol down on the diagram. The Symbol - Object (name) dialog appears.

2. In the Name field, type in the name Customer, and in the Class - (Class) field, type in the name Customer. (We can define the class at this point, but we won't. Let's draw the object first and then go back and define the class.)

You are specifying the object name, and the class that this object instantiates. This class, Customer, is a different class than the one we modeled as an actor in the Use Case of the Reservations package of the previous section. We are purposely separating business classes from logical classes. We could have used the same class (by clicking on the Choices button and dragging it in, or modeling this Sequence diagram in the same package as the Use Cases). This is a design decision we have made.

Create the Sequence Diagram

Drawing an Object Lifeline

Create a Sequence Diagram

12-7

3. Click OK to close the dialog. The object lifeline is drawn on the diagram.

Let's go back and define the class of the object we just drew. 1. Double-click on the object lifeline symbol to open its

definition dialog.

2. Click the Define button in the Class - (Class), Customer field. Let's take a look at its definition.

A class Customer may have many attributes associated with it than the ones listed - for example, Social Security Number, email, age, sex, height, weight, etc. Although many such attributes may immediately come to mind, you must be careful to add only those attributes that are relevant to your design. For example, to make a hotel reservation, we might also want the customer to provide the Credit Card Number that they will be charging. If it were a reservation over the Internet, we might require a return email address. At this point it would be hard to defend why we would need their Social Security Number or their Height and Weight for them to make a reservation.

Let's add the attribute Credit Card Number to the Customer class. To add an attribute to the class:

3. Within the class definition, with the Attributes tab selected, place your cursor in the next empty cell of the Attributes grid, type name and hit your Enter key.

4. In the Type cell, hit the 'c' key on your keyboard to quickly select the char type for this attribute.

Let's add a few more attributes. We'll add the attributes first, then go back and specify a type for each one.

Define the Class

Adding Class Attributes

Figure 12-1 Adding an attribute to a class.


12-8

5. Add the following attributes to the grid, hitting your Enter key after each one to enter it:

address telNo faxNo Credit_Card_Number

Note: When typing in the name of an attribute, you may elect to put spaces in between words (embedded spaces). For example, you could have specified the last attribute added above as Credit Card Number. This is completely okay during analysis. However, most implementation languages (ie, Java, C++) do not allow embedded spaces in attribute or method names. In this tutorial we will not be changing the name of this attribute later during design, so we did not use embedded spaces in the name.

6. Specify each attribute as type char by placing your cursor in the Type column for each one, and hitting your 'c' key on your keyboard.

7. Click OK to close all dialogs.

Figure 12-2 Add additional attributes to the class.

Figure 12-3 Specify the type of each attribute.


12-9

Adding Additional Objects to the Sequence Diagram

So far we have added the object Customer (instantiating the class Customer) to the Sequence diagram. Now let's add the other objects that we found in the steps of the Make Reservation Use Case: Reception, Reservation, Diary, and Room.

To add the object Reception, we will use a different technique than that used previously - we will reuse the class Reception of the package Reservation System that has been preloaded into this project encyclopedia (to make taking the tutorial faster).

1. Right-mouse click on the Sequence diagram workspace, and select Choices. You can view a list of classes and objects already established in this encyclopedia.

2. Select the Reception."Reservation System" class and drag and drop it onto the diagram workspace. Note that there are two Reception classes -- the Reception actor of the Reservations package that we created earlier, and a Reception class of the Reservations System package. Make sure you drag this latter one onto the diagram workspace. An object Reception, instantiating the class Reception, is created. Close the Select and Drag dialog.


12-10

3. Position the object Reception so that it is parallel to the

first object drawn, Customer.

Moving Objects on a Sequence Diagram and Diagram Grid Options: By default, the Sequence diagram employs an invisible, horizontal grid that you draw and move symbols on. You may change the flexibility of this grid, or turn it off altogether, by selecting Format, Diagram Format, Grid and Reduced View. If you want to see the grid on the diagram workspace, select Format, Diagram Format, Display Options, and in the Display Options dialog, toggle on Show Grid. We will not show the grid in this tutorial.

Figure 12-4 Drag-and-drop class onto diagram.


12-11

4. Right-mouse click on the diagram workspace and select

Choices. From the Select and Drag dialog, drag and drop Diary."Reservation System" and Reservation."Reservation System" onto the diagram. Close the Select and Drag dialog. Position the two objects in parallel to the other object lifelines.

Figure 12-5 Object lifelines on Sequence diagram.


12-12

Draw Message/Stimulus Lines Between Objects

Message/Stimulus lines are drawn between objects to show how and when they communicate. These lines (which we'll refer to simply as message lines) are drawn chronologically from the top of the Sequence diagram to the bottom. The message line represents a message sent from one object to another, in which the 'from' object is requesting an operation be performed by the 'to' object. The 'to' object performs the operation using a method that its class, or one if its superclasses, contains. Later in this tutorial, we will specify the method that a 'from' object is requesting the 'to' object to invoke. First, let's concentrate on the messages passed between the objects:

1. Select the Message/Stimulus tool from the toolbox and draw a message/stimulus line, starting at the object Customer and ending at the Reception object. When attaching the Event line to an object lifeline, make sure that you see a + mark on the intersection. This will tell you that the lines are connected. Name the line Query for Available Rooms and press Enter.

Reception responds to the event Query for Available Rooms by performing an action: it must check the Diary for room availability.

2. Draw a message line from the Reception object to the Diary object. Name it Check Room Availability. We will not model the return message from Diary back to Reception -- we will leave it implied.

3. Draw a message line from the Reception object to the Customer object and name it Room Available.

Figure 12-6 Drawing a message between two object lifelines.


12-13

The Customer may now request to reserve the room (we are assuming the Customer already knows the price per night of a room; perhaps this is information provided on the website, or perhaps we've missed this detail and should add it later to our Sequence Diagram). Reception will provisionally book the room in the Diary, which will cause the Reservation to be created. (In this way, no one else can reserve the room out from under this customer while Reception is asking for the Customer to provide a credit card -- an embarrassing situation.

4. Draw a message line between Customer and Reception named Request Reservation.

5. Draw an event line between Reception and Diary named Provisionally Book Room.

Figure 12-7 Messages between objects on Sequence diagram.


12-14

6. Increase the length of the first three object lifeline symbols (all but Reservation), by selecting the symbol and dragging its bottom handlebar downward.

Figure 12-8 Increase length of object lifelines.


12-15

Show Object Creation

The UML notation for showing that an object on a Sequence diagram is created is to draw a message line into the head of the name box at the top of the object lifeline. To show that Reservation is being created in this scenario, we will move the Reservation object lifeline downward so that we can draw a line into its header box.

1. Select the Reservation object and move it down on the diagram so that the next line drawn can be drawn into its 'header box'.

2. Draw a message line from Diary to the header box of Reservation and name it Create Reservation.

Figure 12-9 Modeling creation of an object.


12-16

Complete the Sequence Diagram

The Reservation object will compute its price and notify Reception, which will advise the Customer (Diary is not involved in this pricing process). If the Customer accepts the terms, he/she notifies Reception, which reserves the room in the diary. Diary updates the Reservation status to Reserved.

1. Draw a message line between Reservation and Reception and name it Indicate Total Price.

2. Draw a message line between Reception and Customer and name it Advise Customer.

3. Draw a message line between Customer and Reception and name it Accept Terms.

4. Draw a message line between Reception and Customer and name it Request Credit.

5. Draw a message line between Customer and Reception and name it Provide Credit Card.

6. Draw a message line between Reception and Diary and name it Reserve Room.


12-17

The Sequence diagram should now look like the diagram pictured below.

Note: We might also want to send a message from Reception to another object in the system or outside the system to check the customer's credit before reserving a room. We will not do this in our example tutorial to keep it simple; let's assume the client's credit is checked when he/she confirms the room.

A focus of control rectangle, or activation bar, is drawn on an object lifeline to show the period during which the object is performing an action. The activation bar represents both the duration of the action in time and the control relationship between the activation and its callers. The terms 'focus of control' and 'activation bar' are interchangeable.

1. Select the Focus of Control tool on the toolbox, and drop one onto the Customer object lifeline. Notice that you can only drop a Focus of Control bar onto an object lifeline symbol. System Architect does not allow you to drop it onto empty diagram workspace.

Figure 12-10 First cut of Sequence diagram.

Add 'Focus of Control', or Activation Bars


12-18

2. Choose the Select Mode pointer from the toolbox (or hit your Esc key) to get back your pointer. Select the Focus of Control bar, and drag on its bottom and top handlebars so that it covers the object lifeline at all points where it sends or receives a message.

3. Repeat steps 1 and 2 for the other object lifelines on the diagram. Your diagram should look like the one pictured below.

Figure 12-11 Sequence diagram with Activation Bars added.


12-19

Adding a Method to a Message Line

When one object sends a message to another object, it is in essence asking it to do something. The object receiving the message must be able to perform this task and return an answer to the sending object. The receiving class performs an operation - it uses a specific method to perform this operation. This method can be represented in a programming language such as Java or C++ or Visual Basic, etc.

On the Sequence diagram, you can specify what method is 'invoked' by the sending of a message from one object to another. The method invoked belongs to the class that the receiving object instantiates. In System Architect you may specify what method is associated with each message within the definition of the line. This method should become part of the 'to' class definition, or the definition of a superclass of the 'to' class.

At an early stage of analysis, you would normally not spend too much time figuring out the methods invoked; this would be performed at a later stage of design, when we would return to this diagram. For time's sake, in this tutorial, we will add methods at this point.

Let's model the following: when Reception sends the message Check Room Availability to the object Diary, the method getAvailability is invoked. To reserve the accommodation, we need a start date, the duration of the stay, and the room type. These will be parameters of the method.

1. Open the definition of the Message line Check Room Availability that is sent from the object Reception to the object Diary. (To open the definition, double-click on the line or right-mouse click on it and select Edit.)

2. Click on the Choices button for the Methods property. The Select and Drag dialog will open, providing you with a list of all methods of the target class, Diary. Notice these are only methods for the class Diary (the System Architect notation is to put the method name (with parameters in parenthesis), a period, and the class name.

3. Select the method getAvailability(char, long, char).”Reservation System”.Diary and, holding your left mouse button down, drag it into the Methods field. Close the Select and Drag dialog.


12-20

4. Once you drag the method into the Operations field, you

may optionally click on the Define button to view the full method definition.

5. Click OK to close the Message line definition dialog. You will notice that the name of the method has been added to the diagram, under the Message line.

6. Let's turn off the display of the method name -- right-mouse click on the line and select Display Mode to open the Display Mode dialog. Toggle off Method and click OK.

Figure 12-12 Specify method invoked by message send.


12-21

Adding a New Method to a Class

Next, let's add the method invoked by the message Provisionally Book Room that is sent from Reception to Diary. Let's first add this method to the Diary class:

1. Open the definition of the Diary object lifeline (right-mouse click and select Edit or double-click on the symbol).

2. In the Definition tab of the definition dialog, click on Define next to Class - (Class) Diary to open the class's definition.

3. Within the class Diary's definition dialog, click on the Methods tab. You will notice there are already a number of operations defined for Diary, but no method to book a room. We will add a new method.

4. Cursor to the bottom of the Methods grid, type in bookRoom in the Name cell, and hit your Enter key.

5. Within the method's definition, select the Formal Parameters tab. In the Parameters grid, type in date and press Enter. In the Type cell, hit your 'c' key to select char.

6. Type in a second parameter, roomType, and specify the type as char. Click OK to close the method definition dialog, and OK again to close the class definition dialog.

7. Open the definition of the message line Provisionally Book Room that is sent from the object Reception to the object Diary.

Figure 12-13 Specifying parameters for a method.


12-22

8. Click on the Choices button for the Methods property. The Select and Drag dialog will open, providing you with a list of all methods of the target class, Diary.

9. Select the method bookRoom(char, char)."Reservation System".Diary and, holding your left mouse button down, drag it into the Methods box. Close the Select and Drag dialog and click OK.

Create Collaboration Diagram

12-23

Create Collaboration Diagram The Collaboration diagram is an alternative to the Sequence diagram for modeling the scenarios in your system. Although Sequence diagrams make it easier to see the chronological flow of events, collaboration diagrams enable you to show links between objects, attribute values, and visibility. Let's have System Architect automatically build a Collaboration diagram for us.

1. With the Sequence diagram open and in focus, select Draw, Synchronize Diagram. System Architect will build a Collaboration diagram and, once completed, presents you with a message, The Sequence and Collaboration diagrams have been synchronized. Click OK. The diagram should look similar to the one below.

Building the Collaboration Diagram

Figure 12-14 Collaboration diagram.


12-24

Add a Message to a Link

Let's add a new step to this Collaboration diagram and its sister Sequence diagram.

1. Right-mouse click on the link line between Diary and Reservation and select Associative... from the drop-down menu.

2. The Link dialog opens. Press the New button and in the

Sequence box, enter 13 (this is the next step on the diagram).

3. Type in Update Status to Reserved in the Message/Stimulus box.

4. From the Synchronize drop-down list box, select Asynchronous as the synchronization type. This is an asynchronous message -- it could happen at any time; opposite of this would be a synchronous message, which happens a preset time after the previous step.

Figure 12-15 Adding a message to a link in the Collaboration diagram.

Create Collaboration Diagram

12-25

5. Press Add.


View the diagram and note the changes that you have made in the Collaboration diagram -- a new message appears on the link between Diary and Reservation. The asynchronous message Update Status to Reserved has a symbol next to it that appears as an arrow with a half arrowhead. This is the UML notation for an asynchronous message.

Figure 12-16 Add the message and specify information about it.


12-26

Modify a Message

To modify a message attached to a link:

1. Right-mouse click on the link line between Reception and Customer and select Associative... from the drop-down menu to open the Link dialog.

2. Click on Message/Stimuli 1, Query for Available Rooms, in the Message/Stimuli list box.

3. From the Synchronize drop down list box, select Asynchronous.

4. Click Replace.


Note: diagram Query for Available Rooms now has an asynchronous arrow next to it. Because the diagram is crowded, you may need to move message groups around to make the diagram neater.

Figure 12-17 Finished Collaboration diagram.

Synchronize Sequence Diagram

12-27

Synchronize Sequence Diagram To synchronize the Sequence diagram to include the changes you have made:

1. Select Draw, Synchronize Diagram.

2. Note that the event line Update Status to Reserved has been added between the objects Diary and Reservation, with appropriate synchronization notation. Also the event line for Query for Available Rooms has changed to an asynchronous notation.

Figure 12-18 Finished Sequence diagram.

13-1

13 UML Class Diagram

The UML Class Diagram is the main static analysis and design diagram of a system. It represents the application classes and their associations to other classes and inheritance. There are many methods to building the class diagram; a general approach is to start by modeling the business classes, and then determine your interface layer (for interacting with the end user of the system) and your access layer (for database access).

In the exercises in this chapter you will build a simple UML Class Diagram, reusing some of the business classes already defined in other diagrams and creating some from scratch.

Topics in this chapter Page Create UML Class Diagram 13-2 Begin a New UML Class Diagram 13-4 Cross Referencing Class and Sequence Diagrams

13-15

Create a UML State Diagram 13-18 Mapping the Class Diagram to an ER Model 13-26 Implementing the Design with Code (Java) 13-28

Introduction

In this Chapter…

UML Class Diagram

13-2

Create UML Class Diagram The Class diagram is the main analysis/design diagram for a system. In it, you describe the structure of classes in the system - their identity, relationships to other classes, attributes, and operations. Class diagrams model static behavior. Within the Process Chart that we are using to navigate this tutorial, we are at the following place, highlighted in bold in the picture below:

The class diagram is developed in an iterative fashion, in other words, through a repeated cycle of analysis, design, and implementation.

Often issues that affect the design arise during implementation. Changes made to implementation code need to be reversed back into the analysis model so that iterative design can continue. System Architect facilitates this process by enabling you to implement the design in C++, Java, and Visual Basic, and then reverse that code back into the existing class diagram, automatically updating the information stored on the diagram and in the underlying encyclopedia.

Iterative Design

Create UML Class Diagram

13-3

In the following exercises, you will:

1. Build a very simple class diagram for the hotel reservations system, using classes found through Use Case and Sequence diagram analysis,

2. Add some new classes and design details found through brainstorming,

3. Perform a design check of the Class diagram against the previously modeled Sequence diagrams,

4. Analyze one of the important classes in the application by building a State diagram for it,

5. Map the persistent classes to an Entity Relation diagram to begin the design of the relational database affiliated with the application, and

6. Implement the partial design of the application by generating Java code.

UML Class Diagram

13-4

Begin a New UML Class Diagram We will start by creating a new class diagram.

1. Within the UML tab of the browser, select the Logical View, Reservation System package, right-mouse click on it and select New from the drop-down menu. The Select new type UML dialog appears.

2. Under the Diagrams list, double-click on Class to create a

new Class diagram.

3. In the New Diagram dialog, name the diagram Hotel Reservation System. Click OK. A dialog will present you with the package that this diagram is contained in. Leave it at Reservation System and click OK.

At this point we will reuse the classes that we have already established in the Sequence diagram that we've built within the Reservation System package (and some other classes that already existed in this Tutorial encyclopedia). To place existing classes on the new class diagram:

4. With the UML tab still selected in the browser, within the Reservations System package, click on the + mark by Definitions to reveal all UML definition types that have definitions in this package.

5. Click the + mark by Class to reveal the classes already defined in this project encyclopedia.

6. Hold your Control key down and multi-select the classes Reservation, Reception, Diary, and Customer and drag them onto the desktop of the open diagram. The classes are automatically drawn.

Figure 13-1 Create new Class diagram.

Reuse Existing Classes

Begin a New UML Class Diagram

13-5

7. Arrange the classes as shown in the diagram below. Add space in between the classes to facilitate the drawing of associations between them in the next section.

Figure 13-2 Reuse classes by dragging- and-dropping them onto diagram workspace.

UML Class Diagram

13-6

Building Relationships Between Classes In the UML Sequence diagram, we already established that some of our objects are sending messages to one another. Within the scope of the class diagram, there should be respective associations between the classes that these objects instantiate. At this point we will want to graphically show that these relationships exist. Later, depending on the implementation language, we will want to specify the nature of these relationships (for example, in C++ a class can reference another class, or point to it; in Java, no such notion as 'pointing' exists, but a class can reference another).

In the Sequence diagram we modeled that Diary creates Reservation. It might also cancel it (we would model that in another Sequence diagram) or update its status. We can say Diary Maintains Reservation.

Note: SA offers a number of line styles to select when drawing a line. For this exercise, we will draw using the Straight -- Orthogonal choice. We will switch later to Straight -- Any Orientation.

1. Select Format, Symbol Format, Line.

2. In the Line Style dialog, toggle on Straight – orthogonal and click OK to close the dialog.

To add an association to the diagram:

1. Select the Association line tool from the toolbar, and draw a line from the class Diary to the class Reservation (it is important to draw it in this order). Remember, you must start with a crosshair (+) on the first symbol, release your mouse, and end with a crosshair on the second symbol. Name the line Maintains and press Enter.

2. The name of the association, by default, is placed on the association line.

Add an Association Between Classes

Select Straight – Orthogonal Line Style

Building Relationships Between Classes

13-7

Figure 13-3 Drawing an association between classes.

UML Class Diagram

13-8

Defining an Association Most of the interesting information about an association is attached to its ends. (The association end is part of the association, not part of the class.) An association between two classes contains two association ends. A joint association between three classes (referred to as a ternary association) contains three association ends, etc.

1. Open the definition dialog of the association Maintains between Reservation and Diary (double-click on the line or right-mouse click on it and choose Edit).

The definition of an association contains a grid of the class roles that the association is involved in. Each row in the grid represents an Association End.

The name of the association end is the name of the Role played by that the class for that end. For example, if you had an association Married between the class Man and the class Woman, the role name on the Man side would be Husband and the role name on the Woman side would be Wife. Naming the association end is optional; the name will appear on the association at the end of the class it specifies.

2. Place your cursor in the Name cell for the Diary class and type in Maintainer -- this is the role that the Diary class plays in this association.

3. Place your cursor in the Name cell for the Reservation class and type in Maintainee -- this is the role that the Reservation class plays in this association.

A single Diary maintains zero or more Reservations (zero because it might be possible that at a point in time there are no reservations, although this is unlikely). These numbers are considered the multiplicity of the association.

4. Place your cursor in the Multiplicity grid for Diary, and select Only One from the drop-down list (you may adjust the column width with your cursor). Select Zero, One or Many as the multiplicity for the Reservation side of the association.

Role Names

Specifying Multiplicity

Defining an Association

13-9

A qualifier narrows down the multiplicity of an association. For example, the relationship between classes Diary and Reservation has a multiplicity of one-to-zero-or-more, in other words, one Diary maintains many Reservations. The addition of a qualifier such as Reservation_Number reduces the multiplicity to one-to-one, in other words, a Diary maintains one Reservation_Number.

Put your cursor in the Maintainee Name cell of the Reservation association end, and click on the Define button at the bottom of the grid to open the Association End's full definition dialog.

5. Click on the Qualifier tab.

6. Click on the Choices button in the Qualifier - (Class Attribute) list box.

7. Drag and drop the attribute Reservation_Number into the list box.

8. Click OK to close the Association End definition dialog.

Figure 13-4 Association End information.

Specifying a Qualifier

UML Class Diagram

13-10

9. Click OK to close the Association definition dialog.

Notice that on the diagram, the qualifier appears in a box attached to the Reservation class. You may adjust the positioning of the association name, the role names, and the multiplicities. Notice that System Architect prevents you from moving the role name and multiplicity to the side of the other class. It can only reside on the side of the class it represents.

Figure 13-5 Notations describing association line.

Adding Associations Between Other Classes

13-11

Adding Associations Between Other Classes As we also modeled in the Sequence diagram, Reception uses Diary to gain information for the customer who wants to make a reservation. The association is a one-to-one relationship: there is one Reception class that deals with one Diary class. In addition, each Customer makes one-or-more Reservations. Let's model these associations:

1. Draw an association line from Reception to Diary, and name it uses.

2. Draw an association line from Customer to Reservation, and name it makes.

3. Get out of drawing mode by hitting your Esc key or choosing the Select Mode pointer in the toolbox.

4. Open the definition of the uses association between Reception and Diary and set the multiplicity to Only One for the Reception class, and Only One for the Diary class.

5. Open the definition of the makes association between Customer and Reservation and set the multiplicity to Only One for Customer, and One or Many for Reservation.

UML Class Diagram

13-12

Building Inheritance In our system, we will have various types of customers. In the beginning of this tutorial, we analyzed the problems of the business. We stated that we would be concentrating on business travelers and vacationers. These two classes of customer will have different enough behaviors that we may want to introduce them into our design as separate classes that inherit from the basic Customer class. For example, although a Business Traveler has a name, address, telephone number, fax number, and credit card number that a standard customer has, the business traveler also has a corporate discount, and may be guaranteed a room if their company is involved in hosting a conference in the hotel or at an affiliated conference hall. A vacationer may partake in vacation package discounts.

SA offers a number of line styles to select when drawing a line. We have been using the Straight -- Orthogonal choice. We will now switch to Straight -- Any Orientation.

1. Select Format, Symbol Format, Line.

2. In the Line Style dialog, toggle on Straight – any orientation and click OK to close the dialog.

To model the subclasses Business Traveler and Vacationer on the class diagram:

3. Select the Class tool from the toolbar and add a new class to the diagram, placing it under the Customer class. Name it Business_Traveler.

4. Select the Inherits From line from the toolbar and draw an inheritance relationship from Business_Traveler to Customer.

5. Draw a second class on the diagram, placing it under Customer, and name it Vacationer.

6. Select the Inherits From line from the toolbar and draw an inheritance relationship from Vacationer to Customer.

The existing attributes and methods for Customer do not need to be repeated in the class Business_Traveler or Vacationer. The inheritance line semantically specifies that these 'subclasses' inherit all attributes and methods of the 'parent' class, plus have their own attributes and methods.

Select Straight – Any Orientation Line Style

Model the Subclasses

Building Inheritance

13-13

7. Open the definition dialog for Business_Traveler (double-click on the symbol or right-mouse click on it and select Edit), select the Attributes tab and type in Corporate_Discount as a new attribute. In the Type column, select char. Click Ok to close the dialog.

8. Open the definition dialog for Vacationer, select the Attributes tab and type in Vacation_Package as a new attribute. In the Type column, select char. Click Ok to close the dialog.

Now let's take a look at the Reception class - this is a class that will interface with the end user, or Customer. In our system, Reception may well be a Receptionist that answers the phone at the front desk of a hotel, or at the Hotel's call center at its 1-800 number. Or, it could be a Reservation Order form on the hotel's website. These various forms of reception should be modeled with different classes, since their behavior and capabilities will be different, although they perform the same basic functions, to interface and get information from the customer.

9. Select the class tool from the toolbar and add a new class to the diagram, placing it under Reception. Name it Reservation_Form.

10. Select the Inherits From line from the toolbar and draw an inheritance relationship from Reservation_Form to Reception.

11. Draw a second class on the diagram, also placing it under Reception. Name it Receptionist.

12. Select the Inherits From line from the toolbar and draw an inheritance relationship from Receptionist to Reception.

Building a Second Inheritance Structure

UML Class Diagram

13-14

We have completed our first-cut class diagram.

13. Select File, Save Diagram to save the class diagram.

Figure 13-6 First-cut class diagram.

Cross Referencing Class and Sequence Diagrams

13-15

Cross Referencing Class and Sequence Diagrams At this point we want to make sure that every message modeled between objects on a Sequence diagram has a corresponding association between the respective, instantiated classes, and vice versa. If we were designing a real system, we might have many Sequence diagrams, perhaps hundreds, detailing the scenarios of our system. To make sure these correlations have been made, we can use an automated SA/Word report provided by System Architect. Let's run this report.

Note: you must have Microsoft Word installed on your local machine to run this report.

1. Select Reports, Word Reports, Object Model Reports, Sequence Class Xref Report. Microsoft Word should automatically run, and load a special VBA macro that has been installed into your Word template directory upon installation of System Architect. The UML Sequence Diagram/Class Diagram Interrelationships Report should show up in your Word document.

2. Cursor down through the report - at the end of the report, you should see two informative tables -- Messages with no Association on Any Class Diagram, and Associations with no Events on Any Sequence Diagram.

UML Class Diagram

13-16

The first table tells us is that we have not modeled an association between Reception and Customer on the class diagram, even though a Sequence diagram tells us that there is a relationship between corresponding objects that instantiate them. The second table tells us we modeled an association on the class diagram between Customer and Reservation, but no such relationship exists between any two instantiating objects on any Sequence diagram.

Figure 13-7 Output of Class diagram/Sequence diagram cross-reference report.

Cross Referencing Class and Sequence Diagrams

13-17

In a real project, we would now go back and make appropriate changes to our models to achieve consistency.

3. Close the word report and select No when asked to save the document.

UML Class Diagram

13-18

Create a UML State Diagram The State diagram shows the events that cause a transition from one state of a class to another state. It is a network of states and events. It captures the class’s received stimuli, responses, and actions. Each state receives one or more events, at which time the class transitions to the next state. The next state depends on the current state as well as the events.

Modeling a state diagram is useful for understanding the dynamic behavior of important classes in the system. By important, we mean a class that performs important tasks and may change state often based on system or business events. What is also implied is that you do not need to build a state diagram for every class in the system, just ones you'd like to understand better.

For our system, we may not be interested too much about the dynamic behavior of the Reception class -- Reception is an interface class that is basically getting and providing information from/to a Customer and inputting it into the system. However, we may want to take a deeper look at the Reservation class, since it will be in various states -- like provisionally booked, booked, created, destroyed, on hold, etc. -- based on various events. It is important to understand how long it is in these states, and what events make it change state.

Let's examine the behavior of the class Reservation. Let's create a UML State diagram as a child diagram to the Reservation class:

1. Open the UML class diagram you have built, Hotel Reservation System (if not already open).

2. Right-mouse click on the class Reservation and select Child Create. The Child Create dialog appears.

3. Select State as the type and leave its name at the default Reservation. Press OK.

4. Select Yes to the message asking if you want to save changes to the current diagram. The Diagram - UML State - dialog appears, with the package (Reservation System) and class (Reservation) properties already filled in.

5. Press OK to create the state diagram.

Determine the States and Transitions for a Class

13-19

Determine the States and Transitions for a Class As a general rule, you can look at event lines entering objects of a class on a Sequence diagram to find Transitions for your State diagram. Likewise, you can study the outgoing event lines to find actions that the class carries out while in a particular State. Let's take another look at the Sequence diagram we built named Make Reservation.

Note the messages on the Sequence diagram that enter the object Reservation. These messages, such as Create Reservation and Update Status to Reserved, cause transitions that cause the Reservation to move from one state to another (from the state of being Provisionally Created to the state of being Reserved). If we continued to add details to this Sequence diagram, we might add event lines corresponding to the Customer confirming the reservation, which would put Reservation into the state of being Confirmed. On another Sequence diagram, we might model the scenario for the customer canceling the reservation, transitioning Reservation into the state of being Cancelled. On yet another Sequence diagram, we might model the scenario for the customer's credit not being ok, in which case the Reservation is Denied. You should look at all of the Sequence diagrams on which objects of a

Figure 13-8 Sequence diagram created in previous chapter.

UML Class Diagram

13-20

class are modeled when trying to capture the behavior of a class in a state diagram.

Sometimes it is not clear from the Sequence diagram that an action is performed while a class is in a particular State. With the State diagram, you can discover and capture actions not included in the Sequence diagram.

Drawing the State Diagram

13-21

Drawing the State Diagram Here are some basic rules for drawing a state diagram: States represent the conditions of objects at certain points in time. Events represent incidents that cause objects to move from one state to another. Transition lines depict the movement from one state to another. Each transition line is labeled with the event that causes the transition. Actions occur when an object arrives in a state. From our previous discussion, we note that the states that Reservation can be in are:

• Provisional

• Reserved (we will call this Placed)

• Confirmed

• Denied

• Cancelled

In addition, every state diagram normally has a start state, which in UML notation is a filled in circle, or large bullet. Let's model this:

1. Select the Initial State symbol from the toolbox or Draw menu and place an initial state on the diagram. Name it Receive Inquiry.

2. Select the State symbol from the toolbox and place a state symbol on the diagram. Name the state Provisional.

3. With the State symbol drawing tool still selected (your mouse should resemble a pen), drop down additional states and name them Placed, Confirmed, Denied, and Cancelled. Position the symbols on the diagram workspace as shown in the picture below:

UML Class Diagram

13-22

A transition is represented by a vectored line labeled with the name of the event that causes the transition. So far, throughout most of this tutorial, we have been drawing straight or straight orthogonal lines. For the state diagram, however, we might want to use elliptical arcs for aesthetic reasons. Let's switch the line style.

Change the Line Style to Elliptical Arcs 1. Select Format, Symbol Format, Line. In the Line Style

dialog, toggle on Elliptical Arcs and click OK.

When drawing elliptical arc lines, you can change the direction of the loop -- after left mouse-clicking to attach the start point of the line to a state symbol, release your mouse, and then, before you left-mouse click again to attach the end point to the target state, right-mouse click -- you will notice the arc orientation of the loop in the line change. Continue right-mouse clicking (before left-mouse clicking to attach the line) to toggle between arc orientations.

Figure 13-9 Begin by drawing states that class can be in.

Figure 13-10 Drawing an elliptical transition line.

Drawing the State Diagram

13-23

2. From the toolbox, select the Transition line tool, and draw a transition line between the initial state Receive Inquiry to the state Provisional. Name it Customer Requests Reservation.

3. Using the diagram below as a guide, draw the following transition lines:

• Draw a transition line from the state symbol Provisional to the symbol Cancelled and name it Customer Does Not Accept Terms

• Draw a transition line from the state symbol Provisional to the symbol Denied and name it Credit Not OK

• Draw a transition line from the state symbol Provisional to the symbol Placed and name it Credit OK

• Draw a transition line from the state symbol Placed to the symbol Cancelled and name it Customer did not confirm in 24 Hours

• Draw a transition line from the state symbol Placed to the symbol Confirmed and name it Customer Confirms

The diagram should now resemble the one shown below:

Figure 13-11 First-cut State diagram.

UML Class Diagram

13-24

Defining a State Each state is defined by the actions that are performed during a transition into the state (entry actions), the activities that the class performs while in the state ('do' actions), internal actions that are performed while in the state, and actions that are performed while the class transitions out of the state (exit actions).

Let's take a look at the Provisional state, and reference that Sequence diagram we built. When the Reservation class enters the Provisional state, the reservation is created. This is an entry action (it is performed on entry into this state). While in the state, the Reservation class computes its total price. This is a 'do' action. While in this state, another class, Reception, will find out if the customer's credit is good. We will not model this as an action of the class Reservation. However, if the credit is good, the Diary class will tell the Reservation to update its status to reserved. This event will cause a transition out of the Provisional state to the Placed state.

1. Open the definition of the state Provisional (right-mouse click and select Edit or double click on it).

2. Select the Actions tab, type in the action Create, and hit your Enter key. By default, its When property is set to On entry. Leave the default.

3. Put your cursor in the name cell of the Create action, and click on the Define button at the bottom of the Actions grid to open the full definition dialog for the action.

4. Select the Methods tab. Click on Choices, and select and drag into the list box the method create(long, long, char, char)."Reservation System".Reservation. Click OK to close the dialog.

5. In the Actions grid, type in an action named Compute Total Price, and hit your Enter key. By default, its When property is set to On entry. Place your cursor in this field and change the default by selecting Do.

6. Put your cursor in the name cell of the Compute Total Price action, and click on the Define button at the bottom of the Actions grid to open the full definition dialog for the action.

7. Select the Methods tab. Click on Choices, and select and drag into the list box the method

Add Actions to the State Definition

Defining a State

13-25

CalculatePrice(long)."Reservation System".Reservation. Click OK to close all dialogs.

8. Open the definition of the transition Credit OK. In the

Trigger Event field, type the name of the event that triggers this transition -- Update Status to Reserved.

9. Select File, Save Diagram.

In a real project, we would continue specifying the actions and events for this state diagram to gain a better understanding of the Reservation's behavior. For this tutorial, we will move on to another facet of modeling. Please review the state diagram section of the help for detailed information on advanced state modeling, including super- and sub-states, history, concurrency, etc.

Figure 13-12 Specifying actions for the state.

Specify the Trigger Event of a Transition

UML Class Diagram

13-26

Mapping the Class Diagram to an ER Model So far we have created a class diagram to represent business classes we discovered while doing Use Case and Interaction modeling. We have modeled each of these business classes as a persistent class. A persistent class is one that has a persistent store - it exists after an application has run, and generally stores data. It is opposite of a transitory class - one that is created, used, and destroyed during the course of an application running.

We can use System Architect's automatic mapping capability to map the class diagram we created to a logical Entity Relation (ER) diagram. The ER diagram enables us more capability to model relational concepts, including specification of primary and foreign keys, migration of keys based on relationship types, access paths, etc. Later we can map a logical ER diagram to a physical model representing the specific properties of the DBMS we target for implementation, and then generate working schema (either DDL or to the database directly via ODBC).

During the OO to ER translation, persistent classes and their attributes are mapped to entities. Many-to-many associations between classes are mapped to separate entities in the ER diagram - the name of the entity will be the value defined in the implemented with member variable property of the association, or, if there is no member variable defined, the name of the association itself. Class inheritance structures are mapped directly to entity super/sub relationships in the ER diagram. These super/sub relationships can later be 'flattened' when transforming the logical ER diagram to a physical data model.

To map the UML Class diagram to an ER diagram:

1. Open the class diagram, Hotel Reservation System, in the Reservation System package.

2. Select Dictionary, Convert to ER Diagram. System Architect begins the mapping, and presents you with the Convert OO - ER dialog.

3. In the Convert OO - ER dialog, select Hotel Reservation System from the drop-down list.

4. In the Destination Diagram field, type in Reservation System as the name of the diagram.

Mapping the Class Diagram to an ER Model

13-27

5. Leave the default All Symbols selected in the Transfer group. This will map all classes on the currently open diagram.

The new ER model is created.

6. Select File, Save Diagram.

Figure 13-13 Entity relation diagram created from Class diagram.

UML Class Diagram

13-28

Implementing the Design with Code (Java) During design, you add further details to associations and class definitions that are necessary for implementing the system. System Architect supports automatic generation of code from a class diagram for a number of languages, including Java, C++, Visual Basic, and CORBA IDL. System Architect also supports reversing code into a class diagram for Java, C++, and Visual Basic.

System Architect provides script-based code generation for a number of languages. Code generation is performed by selecting a code generation script that is located in the <c>:\Program Files\Popkin Software\System Architect\Basgen directory. There are scripts for Java (java.bas), JavaScript (javasc.bas), and CORBA IDL (corba.bas). The script-based code generator generates code to a file or files. These files can then be used in any Interactive Development Environment (IDE).

For C++, System Architect provides a 'hard-wired' generator, which produces header (.hpp) and skeleton (.cpp) files.

In addition, for Visual Basic 6.0, System Architect provides a synchronization wizard (select Tools, Synchronization Wizard) to synchronize a class diagram with an open Visual Basic project. The wizard provides a direct tie-in between System Architect and the IDE.

Code Generation Capabilities

Generating Java

13-29

Generating Java Let's now generate Java code for our first-cut class diagram.

To select the code generator:

1. With the Hotel Reservation System Class diagram open, select Dictionary, Forward and Reverse Code Engineer. The Forward and Reverse Code dialog opens.

2. From the Selection menu, make sure that Export All is toggled on.

To set the export options:

3. From the Options menu, select Script Gen... to open the Set Basic Script File dialog.

4. Select the Java.bas file in the Basgen subdirectory (<c>:\Program Files\Popkin Software\System Architect \Basgen), and click Open.

5. In the Forward and Reverse Code dialog, select File, Logging. Make sure Log to File and Log to Screen are checked on.

To export:

6. In the Forward and Reverse Code dialog, select File, Export, Via Script to open the Export using script dialog.

7. Click on Browse. In the Open dialog, navigate to the path <C>:\Program Files\Popkin Software\System Architect \Encyclopedias\Tutorial. In the Files of type drop-down list, select Java Files (*.java). In the File name field, type in the name tutorial. Select Open to close the dialog.

8. Back in the Export using script dialog, select Use default path/file for all selected classes as the Output File Specification.

Note: For the Java language, each class is normally represented in a separate file with .java extension. To do this in System Architect, we would select Use class generation path/file specified in class definition. For this tutorial, we will generate the entire class diagram to a single file so we can look at it all in one place.

9. Press Export. Java code is generated for the classes selected. System Architect displays a report, Summary.log, which details what classes were generated and to what file(s) they were generated to.

Selecting the Code Generator

Select the Java.bas Code Generation Script

Export the Classes

14-1

14 Logical Data Modeling

In this part of the tutorial, we will use data modeling techniques to model the relational database design of the hotel reservation system. We will start by modeling the logical entities, and how they should be related. Later we will design the physical implementation of the database in a physical data model.

In this chapter, you will develop a logical entity relation model for the hotel reservation system.

Topics in this chapter Page Logical Data Modeling 14-2 Creating a Subject Area of the Data Model 14-4 Creating a new ER Diagram 14-5 Creating a Second Subject Area Diagram 14-21 Creating a Model Diagram 14-25

Introduction

In this Chapter…

Logical Data Modeling

14-2

Logical Data Modeling The entity relation diagram is a logical representation of the data structure and data relationships of the database. It focuses on what is represented in the database (not how it is represented, which is covered in the physical diagram). It includes entities to represent each person, place, event, or concept about which information will be maintained in the system, and relation lines to represent the associations between the entities.

There are many techniques to finding the entities of a new system. If you have worked through the UML portion of this tutorial, you used Use Cases and Sequence diagrams to discover business objects and classes; the persistent classes can correlate to logical entities. Another technique, independent of object/UML modeling, is to model the business as it is, or as it should be, with process flow diagrams (Process Charts or IDEF3 Process Flow diagrams, for example) and discover the entities from these descriptions of the business. Or you may brainstorm to find entities during Contextual stage of modeling, and use these entities to build a conceptual data model.

In the Conceptual Data Model, you concentrate on what the entities of your system might be, and decide which ones are related to one another. You should not concern yourself with much information more than this, for example what the attributes of the entities are, or what the multiplicities of the relationships are. A simple textual description of each entity, or perhaps some attributes, will suffice. To build a Conceptual Data Model in System Architect, you would use an ER diagram, and use the Non-specific relation line to model relationships between entities. We will not specifically model a Conceptual Model in this tutorial.

From the conceptual model, you can develop a logical model. In the logical model, you take the conceptual model and start adding details. You can replace the Non-specific relation line between entities with Identifying or Non-Identifying relationships. You model the attributes of the entities, and specify their generic data types. You can normalize your model, and specify which attributes are primary and foreign keys for the entities. You might even specify access paths for the entities - ways in which entities can be navigated to find information quickly - similar to indexes in the physical diagram.

Within the context of the tutorial process map, we are at the stage of modeling shown in the picture below.

Conceptual Data Model

Logical Data Model


14-3


14-4

Creating a Subject Area of the Data Model In this section we will create a small data model diagram for a piece - or subject area - of our system. We will create it as a subject area data model, and later, create the overall model diagram. If you have worked through the UML portion of this tutorial, you have already created a subject area for part of the reservation system. This section is independent of your having worked through the UML section - we will start afresh with building a data model in System Architect.

In the UML section of this tutorial, we used Use Cases to model scenarios in the system, and from that discovered business objects, some of which were persistent classes that we mapped to entities. In the business modeling section of this tutorial, we used Process Charts to model the major Process Threads of the organization. While building these Process Charts of the 'as is' or 'to be' system, we can discover entities (although we did not cover it in this tutorial, you can establish entities for each business event or process). Another technique for establishing potential entities is to brainstorm and come up with a list.

Let's think about how a customer checks in to the hotel. We have a customer with a reservation, who we can think of at this point as one or more guests (customer with companion or family members) who approaches a sales clerk, who checks the customer and companions (rest of family, etc) into a room. The customer checks into the hotel during a certain time of the day, which correlates to a shift that is manned by a certain number of sales clerks. The customer may have a vehicle that they need to park in the hotel parking lot. Let's model how the following entities are related:

• Guest

• Reservation

• Shift

• Room

• Vehicle

Scenario for Checking Into Hotel

Creating a New ER Diagram

14-5

Creating a New ER Diagram Let's create a subject area data model for checking into a hotel:

1. Select the Data Modeling tab in the browser.

2. From the File menu, select New Diagram. (In the Data Modeling tab of the browser, you may also click on the + mark to expand Models, then Hotel Reservation System, and then right-mouse click on Diagrams and select New.)

3. A dialog will open presenting you with a list of possible

diagram types. Double-click on Entity Relation.

4. In the New Diagram dialog, enter the name of the diagram to be created, Hotel Check-In, and click OK. The Diagram-Entity Relation dialog opens. In this dialog we will specify whether this is going to be a model diagram or a subject area of a model. In either case, we must specify the model that we are representing.

5. If not already selected, toggle on Subject Area for the Diagram Status property.

6. For the Model property, click on the Choices button. The Select and Drag dialog will open, presenting a list of models already created in this project encyclopedia. The dialog should only display the model Hotel Reservation System.

7. Select and drag Hotel Reservation System into the Model property box and close the Select and Drag dialog (by clicking on X in its upper right-hand corner). (If no model existed at this point, you could type a new model name in the box and click Define to create it.)

Figure 14-1 Create a new ER diagram.


14-6

8. You do not have to select a DBMS at this point. You can

leave it at its default, ANSI. (Note: the selections presented in this list are dependent on the Database Properties you selected in the Customize Method Support dialog. To add different DBMS's to this list, you would select Tools, Customize Method Support, select one or more DBMS's in the Target Databases list, and reopen the encyclopedia.)

9. Click OK to close the dialog and create the Entity Relation diagram.

Figure 14-2 Specifying the model of the Subject Area ER diagram.


14-7

Drawing Entity Symbols

A Hotel Guest has a Reservation that enables them to have a Room (or the room belongs to them). The guest may own a car (or Vehicle) that they wish to park, in which case Reception needs to know the license plate number of the car, and the guest it belongs to. Let's draw the entities Hotel Guest, Reservation, Room, and Vehicle. To place a new entity symbol:

1. Select the Entity symbol from the Draw toolbar and click on the diagram work area where you want the symbol to be placed - select a spot in the middle of the diagram workspace - leave room to add entities above it, as we will do later. The entity symbol appears with the default name, Entity_1, selected.

2. Overtype the default name with Hotel Guest and press Enter.

3. You should still be in draw mode - your cursor will look like

a pen when you position it over the diagram workspace. Use the same procedure described in steps 1 and 2 to add another new entity, this one called Vehicle. Position it below Hotel Guest.

4. To turn the drawing cursor off, click the entity symbol (or the cursor arrow) on the Draw toolbar again.

Let's reuse the Reservation entity, already established in our project encyclopedia.

5. Right-mouse click on the diagram workspace and select Choices from the drop-down list. You will get a list of all existing definitions of types that can be drawn on this diagram. In this case, you get a list of all entities already defined in this project.

Figure 14-3 Naming the entity via on-screen editing.

Reusing an Entity from the Project Encyclopedia


14-8

6. Select Reservation and drag and drop it onto the diagram workspace, to the right of Hotel Guest. Notice that the entity is drawn complete with all of its already defined attributes.

7. Also select Room from the Select and Drag dialog, and

drag it onto the diagram workspace above Hotel Guest. Notice that it too is drawn complete with all of its already defined attributes.

8. Close the Select and Drag dialog. Your diagram should look like the one below.

Figure 14-4 Drag-and-drop existing entities onto the diagram workspace.


14-9

Figure 14-5 Entities for Reservation System.


14-10

Defining Entities

System Architect provides an underlying data dictionary of data elements and data structures that can be used in various definition types throughout the tool (entities, tables, UML classes, business processes, etc). A data element is an elemental piece of data. It can have a data type, and various other properties. A data structure is a grouping of data elements. For example, you may have data elements such as Name, Street Address, City, State, and Zip Code. You might optionally combine all of these into a data structure called Address. Within an entity, an attribute is considered an instance of a data element or a data structure.

Let's define attributes for the Hotel Guest entity.

1. Open the Hotel Guest entity’s definition dialog by double-clicking on the entity symbol and choosing Edit from the drop-down menu, or selecting the symbol and choosing Edit, Entity from the toolbar. This will open the Model Object - Entity dialog.

Note: If you want the entity definition dialog to appear automatically each time you place an entity symbol on your diagram, from the Tools menu, select Preferences and check Auto, Define.

Using the Underlying Data Dictionary Let us first examine the data elements already residing in our underlying data dictionary for this project encyclopedia, to see if we want to reuse any for this entity.

2. Click on the Choices button in the bottom right-hand corner of the Attribute list box of the Attribute tab to open a list of all data elements and data structures already defined in the underlying data dictionary.


14-11

Creating Data Elements: System Architect 2001 allows you to define a data elements and data structures before you use them in entities. In this way you establish an underlying data dictionary that you can continue to build on as you define data in or outside of entities. To create a new data element or structure by itself, simply select Dictionary, New Definition, and double-click on Data Element found under the Shared folder, Definitions. You may also create a new data element definition in the browser - in the All Methods tab, expand the Definitions type, and right-mouse click on Data Element and select New. Or, if you are in the Data Modeling tab, expand the Shared folder, expand Definitions, and right-mouse click on Data Element and select New.

3. Hold down your CTRL key and multiple-select the data elements Guest_Number and name. Hold down your left mouse button and drag them into the Data column of the Attributes List grid (aim for the first cell). Two new attributes for this entity are created.

4. By default, System Architect names the attributes

Guest_Number and name. You can change these names without affecting the names of the underlying data elements that the attributes report to.

Figure 14-6 Reuse data elements from underlying data dictionary.


14-12

5. Close the Select and Drag dialog.

As mentioned at the start of this section, the attribute is considered the instance of the data element within this entity. It carries instance information, such as whether or not this data is a primary key for this entity, whether or not it is a foreign key, whether or not it can be null, etc. The data element carries the overall information on this piece of data - its data type, qualifiers, default value, etc.

6. Place your cursor in the Name cell of Guest_Number to highlight the whole attribute name. Type over this name to change it to Guest#. Notice that the data element name (in the cell to its left) does not change.

Figure 14-7 Specify name of attribute to be different than data element name.


14-13

Specifying Primary Keys

The primary key of an entity is the attribute, or attributes, which uniquely identifies an instance of the record represented by the entity. To specify Guest# as the primary key attribute:

1. Toggle on the PK cell adjacent to Guest#. This makes this attribute the primary key for this entity.

2. Place your cursor back in the cell for the attribute Guest# and click on the Define button at the bottom of the Attribute List box. You will open the full definition dialog for this attribute. Notice that in the Attribute Designation group, the property Primary Key is toggled on. Click OK to close the dialog.

3. Place your cursor in the Guest_Number cell of the Data column and click on the same Define button at the bottom of the Attributes List grid. You will open the full definition of the underlying data element. Notice that the properties and their values in this dialog are identical to those in the previous dialog for the instantiating attribute, except that this dialog does not contain the Attribute Designation group.

4. Close the data element dialog.

Effects of Changes to Data Elements and Attributes: If you change any values in the data element dialog, they are applied globally across the data model - they change for the data element, and all attributes that use the data element in all entities across the model. The same goes if you change a value in the attribute definition dialog - it will change the corresponding value in the underlying data element, and be applied globally across the model.

1. Click on the Choices button in the Attributes List grid

again.

2. Right-mouse click anywhere within the Select and Drag dialog and select Details.

3. Select the data structure address (located at the bottom of the list -- the list alphabetically lists names with capital letters first, then lists names with first letters that are lower case). Notice that in the Details window, this data structure is shown to include the data elements Street, Town, and

Adding a Data Structure as an Attribute


14-14

District. Drag and drop it into the Data column of the Attributes List grid (aim for the next available cell). A new attribute for this entity is created.

Note on Expanding Data Structures: At this point you could choose to expand this data structure into its constituent data elements in the Attribute List grid. We will not do it here. When we map this logical data model to a physical model, and this logical entity and its attributes are mapped to a table with columns, this data structure will be automatically decomposed into an equivalent column for each of its data elements.

If you did wish to expand this data structure now, you would right-mouse click on address in the Data column cell, and select Expand from the drop-down list. After expanding it, a column (titled Data Structure) in the Attribute List grid (located to the far right) would detail the data structure that each resulting element was expanded from.

4. Click OK to close the entity definition dialog.


14-15

Creating New Data Elements in an Entity

Now let's add some new attributes to an entity, thereby also creating new data elements in our data dictionary. We will add attributes to the Vehicle entity.

1. Open the definition dialog for the Vehicle entity (double-click on the symbol or right-mouse click and select Edit).

2. On the Attributes tab, within the Attribute List grid, place your cursor in the first Data cell and enter the name for a new data element, License_Plate_Number and hit your Enter key. Notice that in the grid, default values for the attribute's Data Type and Qualifiers are entered. The default value for Data Type is Character. The default value for Qualifiers is 10. What this means is that in the eventual database that will be built from this design, there will provisions for storing license plate numbers that can contain a combination of up to 10 characters (or numbers).

3. Toggle on the PK cell for License_Plate_Number to make this the primary key for the Vehicle entity.

4. Enter another attribute called License_Plate_State and hit Return. Leave its default values for Type and Qualifiers. Toggle on the PK cell for this attribute as well - we now have a two-part primary key for this entity.

5. Enter another attribute named Make, and hit Return. Again leave the default values for Data Type and Qualifiers.

6. Enter another attribute named Color and hit Return. Leave the default values for Data Type and Qualifiers.

7. Enter one more attribute, named Year, and hit Return. This time we'll change the default values of Data Type and Qualifiers.

8. Place your cursor in the Data Type field so that a drop-down arrow appears. Click on the arrow to display a list of available data types. Notice that these are generic ANSI data types - they are not DBMS specific. That is because we are in a logical entity. When we map this diagram to a physical data model, System Architect will map generic


14-16

data types to DBMS-specific data types, depending on the DBMS we choose to model in the physical data model.

9. In the drop-down list of data types, find and select Integer.

10. Put your cursor in the Qualifiers cell for the Year attribute, and overwrite the default value 10 with 4. This means that a year for a vehicle in our database will be 4 integers.

11. Click Ok to enter the attributes onto the entity symbol.

Column Name

As we model in this logical data model, System Architect is already preparing for mapping to a physical data model. If you use the bottom scroll bar in the Attribute Grid, and scroll to the right, you will notice a column called Column Name. Notice that the name of the data element is automatically mapped to a default column name - this is the name of the column that will be created for a corresponding table of this entity, when we map this diagram to a physical model. You may manually change the name of the column right here in the attribute grid.

You may specify the way that this mapping is done by selecting Dictionary, Options, Column Name Options. Please refer to the on-line help for details.

Figure 14-8 Specify a data type for the attribute.


14-17

Drawing Relationship Lines

Let's draw a relationship line between Hotel Guest and Vehicle:

1. From the Draw toolbar, choose the Identifying Relation line.

2. Click and release your left mouse button over the Hotel Guest entity. A + mark appears, indicating that a line is attached to the entity.

3. Click your mouse on the Vehicle entity. A + mark appears, indicating that the line is attached to the entity. Release the mouse button to attach the line.

4. A cursor appears on the relation line, specifying a name. Name the relation line Owns and click on your left mouse button.

Notice that the Vehicle entity now has a double line around it - it has been transformed to a Weak Entity to reflect the fact that a Hotel Guest record must exist for a Vehicle to exist.

If you select Tools, Preferences, and toggle on the Auto-Define choice, the Relationship Editor will appear automatically each time you place a relation line on a diagram. By default, this choice is toggled off -- in this exercise we will first draw the relationship lines between entities, and then go back and define them.

5. You should still be in draw mode -- your cursor should still resemble a pen. Using the procedure for drawing lines described in steps 2 and 3 above, draw a relationship between Room and Hotel Guest. Name the line belongs to.

Notice that the Hotel Guest entity now has a double line around it - it has been transformed to a Weak Entity to reflect the fact that a Room must exist for a Hotel Guest to exist.

6. You should still be in draw mode. Using the procedure for drawing lines described in steps 2 and 3 above, draw a line between Reservation and Hotel Guest and name it belongs to.


14-18

Figure 14-9 First-cut Entity Relation diagram.


14-19

Updating Foreign Keys

1. Select Dictionary, Update FKs. System Architect will examine the data model, and establish foreign keys in child entities based on the relationship types between entities. This is also referred to as migrating foreign keys.

2. Close the Foreign Key Propagation dialog.

The logical data model should look like the one pictured below.

Figure 14-10 Finished ER Subject Area diagram.


14-20

3. Open the definition dialog for the Owns identifying relationship line between Hotel Guest and Vehicle (double-click on it or right-mouse click on it and select Edit).

In the definition dialog that opens, notice that on the Parent Entity side of the relationship, the Parent identifies child box is toggled on. This is an identifying relationship. The primary keys of the parent entity (Guest# and number) are migrated through this relationship into the child entity. They will be 'foreign' keys in the child entity Vehicle. The primary key number was migrated into Hotel Guest from its relationship to Room.

4. Click OK to close the Owns relationship definition dialog.

System Architect provides you with a number of display options for the logical ER diagram. Let's examine them.

1. Right-mouse click on the entity Hotel Guest and select Display Mode from the drop-down list. You are presented with a dialog that gives you a number of choices for display.

2. Within the Display View group, select Key Based and click OK. Notice that only the primary and foreign keys are displayed on the entity symbols.

3. Right-mouse click on an entity (any entity) again and choose Display Mode. Change the display mode to Fully Attributed and click OK.

4. Select File, Save Diagram to save the diagram.

5. Select File, Close Diagram to close the diagram.

Migrating Keys

Display Options

Creating a Second Subject Area Diagram

14-21

Creating a Second Subject Area Diagram The steps on this page are optional if you have already created a second subject area diagram by performing the steps of the previous section -- creating a UML class diagram and mapping it to a data model. If you have not worked through the previous chapter, then follow the steps on this page to create the data model below. (Otherwise, jump to the next section, Creating a Model Diagram.)


2. From the File menu, select New Diagram. A dialog will open presenting you with a list of possible diagram types. Double-click on Entity Relation.

3. In the New Diagram dialog, enter the name of the diagram to be created, Reservation System, and click OK. The Diagram-Entity Relation dialog opens. In this dialog we will specify whether this is going to be a model diagram or a subject area of a model. In either case, we must specify the model that we are representing.

4. For the Diagram Status property, toggle on Subject Area (it should be toggled on already since this is the default).

5. For the Model property, click on the Choices button. The Select and Drag dialog will open, presenting a list of models already created in this project encyclopedia. You should see the model Hotel Reservation System.

6. Select and drag Hotel Reservation System into the Model property box and close the Select and Drag dialog (by clicking on the X in its upper right-hand corner). (If no model existed at this point, you could type a new model name in the box and click Define to create it.)

7. Leave DBMS at its default value, ANSI. (Note: the selections presented in this list are dependent on the Database Properties you selected in the Customize Method Support dialog. To add different DBMS's to this list, you would select Tools, Customize Method Support and reopen the encyclopedia.)

8. Click OK to close the dialog and create the Entity Relation diagram.

Create the Subject Area Diagram


14-22

1. Right-mouse click on the diagram workspace and select Choices. Drag and drop onto the diagram workspace the entities Reservation and Customer.

2. Create new entities Reception, Receptionist, Reservation_Form, Diary, Business Traveler, and Vacationer, referring to the diagram below for placement of the entities.

3. Select the Super-sub Relation line, and draw a line from Customer to Business Traveler, and another line from Customer to Vacationer.

4. Select the Super-sub Relation line, and draw a line from Reception to Receptionist, and another line from Reception to Reservation_Form.

5. Select the Non-Identifying Relation line, and draw a line from Customer to Reservation. Name the line makes.

6. Select the Identifying Relation line, and draw a line from Reservation to Diary. Name the line maintains.

7. Select the Identifying Relation line, and draw a line from Diary to Reception. Name the line is used by.

8. Add the following attributes to the following entities (typing them into the attribute grid and pressing Enter after each one):

Entity Add the Following Attribute(s) Diary Diary_ID (and toggle on PK)

RoomTypeAvailability Reservation Reservation_Number (and toggle

on PK) Business Traveler Corporate_Discount Vacationer Vacation_Package_Discount Receptionist employeeID (and toggle on PK)

Draw the Diagram

Creating a Second Subject Area Diagram

14-23

Your diagram should look like the one below:

1. Select Dictionary, Update FKs. System Architect will examine the data model, and establish foreign keys in child entities based on the relationship types between entities. This is also referred to as migrating foreign keys.

Figure 14-11 Second Subject Area ER diagram.

Update Foreign Keys


14-24

2. Close the Foreign Key Propagation dialog. The diagram should now look like the one below:

3. Save the diagram by selecting File, Save Diagram.

Figure 14-12 Second ER Subject Area diagram with Foreign Keys migrated.

Creating a Model Diagram

14-25

Creating a Model Diagram We have thus far created two subject area diagrams for the Hotel Reservation System Model. Now let's bring them together into one model diagram. The model definition Hotel Reservation System already exists, but we have not yet created a diagram to represent it.


2. From the File menu, select New Diagram. A dialog will open presenting you with a list of possible diagram types. Double-click on Entity Relation.

3. In the New Diagram dialog, enter the name of the diagram to be created, Hotel Reservation System Model Diagram, and click OK. The Diagram-Entity Relation dialog opens.

4. For the Diagram Status property, toggle on Model.

5. For the Model property, click on the Choices button. The Select and Drag dialog will open, presenting a list of models already created in this project encyclopedia. Select and drag Hotel Reservation System into the Model property box and close the Select and Drag dialog (by clicking on the X in its upper right-hand corner). Leave DBMS at its default value, ANSI.


14-26

6. Click OK to close the dialog and create the Entity Relation diagram. The diagram will be created and all entities and relationships from affiliated subject area diagrams will be automatically drawn on the model. Note that there are entities and relationships on the diagram that you did not include on either of your subject area diagrams. These entities and relationships were already in the model of this encyclopedia.

Figure 14-13 Entity Relation Model diagram.

15-1

15 The Physical Data Model

System Architect enables you to model with a physical data model that is a separate diagram from the logical data model. This allows you to model the physical design of your database independently of your logical design. You can tailor your physical design for your implementation DBMS, and even create multiple physical designs off of one logical design.

In this chapter we will map the logical data model we created in the previous chapter to a physical data model, targeting the Oracle DBMS.

Topics in this chapter Page The Physical Data Model 15-2 Creating the Physical Diagram 15-4 The Physical Table 15-8 Display Options for a Table 15-11 Modeling Constraints Between Tables 15-12 Generating Schema 15-13 Reversing Database Designs 15-15

Introduction

In this Chapter…

The Physical Data Model

15-2

The Physical Data Model There are two main reasons for separating logical and physical database design: • To enable modeling of normalized and denormalized designs.

• To enable modeling of distributed databases.

When designing a database system, it is often advantageous to adhere to the rules data normalization during the logical design stage. This assures that data redundancy is minimized. More often than not, however, the implemented database is not normalized (or denormalized) to make retrieval times of data faster.

By separating the logical and physical design stages, the logical design can be normalized and the physical data model (which can be automatically generated from the logical) can be denormalized.

Distributed systems are logically one database system but are physically multiple database systems. Separation of logical and physical models allows distributed databases to be effectively modeled and reported on. The Project Data Model can be comprised of multiple subject area ER diagrams. Each ER diagram can represent a different database in the distributed system. A physical model can be generated from each entity relation model. Since the ER Model diagram displays all subject areas in an individual diagram, and all entity and relationship definitions are shared within an individual project model, it is easy to visualize and report on relationships between the various databases that are included in the system. In this section you will automatically build a physical diagram from the logical model built in the previous chapter. In terms of the tutorial scenario map that we are following, we will perform the process indicated in bold below:

Database Denormalization

Database Distribution

In this Section


15-3


15-4

Creating the Physical Diagram To create a physical representation of one of the logical diagrams created in the previous chapter, perform the following steps:

1. Open the logical model diagram Hotel Check-In (if it is not still open, in the Data Modeling tab of the browser, expand Models, Hotel Reservation System, Diagrams, Entity Relation, and then double-click on Hotel Check-In (or drag it onto diagram workspace).

2. Select Dictionary, Create Data Model, Physical Data Model. The Create Physical Data Model Diagram dialog opens.

Super/Sub Resolution Method:Within this dialog, you may specify how you want to map super-sub relationships in the logical ER diagram to physical tables - a physical table does not understand inheritance; it only knows about the columns contained within it, it cannot inherit columns from another table. The choices are as follows:

Separate Tables: creates a separate physical table for every entity in a super-sub grouping. Attributes for each entity are mapped to columns in each respective table.

Merge Supertype to Subtype: creates tables for all sub-entities, does not create a table for the super-entity. Each table created for a sub-entity contains columns mapped from the attributes of the corresponding sub-entity, plus attributes 'handed down' from the super-entity.

Merge Subtype to Supertype: creates one table for the whole super-sub entity structure. Attributes from all super- and sub-entities are mapped to columns in the one table created.

Prompt for Each Super/Sub Group: System Architect will prompt you with a dialog enabling you to choose the mapping for each Super/Sub group as the transformation of logical to physical diagram takes place.

In addition, the Create Physical Data Model Diagram dialog enables you to globally choose how the case (upper, lower, or retain) of

Name Mapping

Creating the Physical Diagram

15-5

names of Tables (corresponding to Entities in the ER diagram), Columns (corresponding to Attributes in entities), Constraints (corresponding to Relationships between entities), and Indexes (corresponding to Access Paths) are mapped.

3. Leave the default choice for all choices on the Create Physical Data Model Diagram dialog (Separate Tables, and Retain Case), and click OK.

4. System Architect will begin the mapping (a running log detailing the mapping will appear on the screen, under the title Generate Physical Data Model).

5. System Architect presents you with a dialog in which you must select the Model and DBMS for the physical diagram. Select the drop-down list by DBMS, and choose Oracle 8. (Keep Model at its default, Hotel Reservation System, and leave Database Name empty.) Click OK.

Note: the number of DBMS's listed depends on the DBMS's chosen in the System Architect Property Configuration dialog. The list of DBMS's can be changed at any time during a project by selecting Tools, Customize Method Support, Encyclopedia Configuration, selecting DBMS's from the Target Databases list, and reopening your encyclopedia.

6. The physical diagram is created, and the Generate Physical Data Model running log dialog completes.


15-6

Note: at this writing, the shipping version of System Architect does not display a 'Diagram Created' message in the log dialog; when the diagram is completed, the log dialog simply shows a blinking cursor. In addition, the physical diagram created will be off to the right on the diagram workspace, and not necessarily be visible on the screen. To view the diagram, perform the step below.

7. Close the running log by clicking x in its upper right-hand corner. Select View, Used Area to view the entire physical diagram.

8. Select File, Save Diagram to save the diagram.

Figure 15-1 Specify the DBMS of the physical model.

Creating the Physical Diagram

15-7

Figure 15-2 Physical diagram.


15-8

The Physical Table The physical table represents the design of the table that will be implemented in the database. It contains specification of the table's columns (not the rows, obviously, since the rows correlate to the actual data itself, which is stored in the database and has nothing to do with the design). Let's examine a table in our physical diagram.

1. Notice the table Hotel_Guest. In the logical ER model there was an embedded space in its name - 'Hotel Guest'. Since Oracle does not deal with embedded spaces in names of tables or columns, System Architect has added an underscore to the name - you specified this in the Create Physical Data Model Diagram dialog by leaving the "_" for Special Characters choice toggled on for tables.

2. Select the table Hotel_Guest. Open its definition by right-mouse clicking on it and selecting Edit, or simply double-clicking on it.

3. Notice in the Column grid of the table's definition dialog, that the columns have been mapped over from corresponding attributes in the corresponding entity of the logical data model. Notice also that the data types are all upper case - the generic data types in the logical model have been mapped to Oracle-specific types.

The Physical Table

15-9

4. Notice that Hotel Guest has columns Street, Town, and

District. If you remember in the logical model, we added the data structure Address to the logical entity for Hotel Guest. The data structure was composed of data elements Street, Town, and District. The data structure has now been expanded into relevant columns in the physical table.

5. Notice that this table contains a number of new primary keys - Number, ID, and Identifier - that have been migrated from other tables as foreign keys (both the PK and FK cells are checked for each).

6. Notice the column Guest_Number - remember that in the logical entity, the name of the logical data element was Guest_Number (with an embedded space), and the attribute name was Guest#. The data element has been mapped over.

7. Select Guest_Number (put your cursor in its name box) and click the Define button at the bottom of the Column grid. You open the full definition dialog for this column.

8. Select the Source and Key Info. tab. In this tab, you can see the source attribute and data element for this column. It

Figure 15-3 Table definition.


15-10

is read-only information. You may click the Define button to view full information on either source item.

9. Click OK or Cancel to close all dialogs.

Display Options for a Table

15-11

Display Options for a Table System Architect provides you with a number of display options for the physical diagram. Let's examine them.

1. Right-mouse click on the table Hotel_Guest and select Display Mode from the drop-down list. You are presented with a dialog that gives you a number of choices.

2. Select Key and click OK. Notice that only key columns are displayed on the table symbols on the physical diagram.

3. Right-mouse click on a table (any table) again and choose Display Mode. Change the display mode back to Columns and click OK.


15-12

Modeling Constraints Between Tables A constraint in the physical data model is the equivalent of a relationship line in an ER diagram. The constraint line in the physical diagram is actually a visual representation of the foreign key constraints in the database represented by the diagram. The constraint can be specified as identifying or non-identifying. An identifying constraint indicates that the foreign keys are primary key components of the child table. A non-identifying constraint indicates that the foreign keys may be non-key columns in the child table.

1. Open the definition dialog for the owns constraint line between Hotel_Guest and Vehicle (double-click on it or right-mouse click on it and select Edit).

2. Notice that you can change whether this line is identifying or non-identifying (child optional) through the dialog.

3. Click Cancel or OK to close the dialog.

Constraints

Generating Schema

15-13

Generating Schema You can generate schema from a physical diagram for your implementation DBMS. System Architect provides a choice of generation to a DDL file, or directly to the DBMS through ODBC for most DBMS's. Let's generate schema for Oracle 8 for our data model.

1. Open the physical model diagram Hotel Check-In (if it is not still open, in the Data Modeling tab of the browser, expand Models, Hotel Reservation System, Diagrams, Physical Data Model, and then double-click on Hotel Check-In (or drag it onto diagram workspace).

2. Select Tools, DB Schema Generation. The System Architect Schema Generation dialog opens.

3. In the System Architect Schema Generation dialog, click the Select menu - notice all tables are selected. Click Cancel.

4. In the System Architect Schema Generation dialog, use standard Windows techniques (hold down SHIFT key) to select all of the properties to be generated in the Output(s) list.

Figure 15-4 Schema Generation dialog


15-14

5. Select the Generate button. The Oracle 8 DDL will be generated and output to a file. The file will be presented within Notepad on the screen. You may open this file in Oracle 8 to view the database.

Figure 15-5 Specify the DBMS of the physical model.

Reversing Database Designs

15-15

Reversing Database Designs System Architect provides the ability to reverse database designs into a physical diagram. For most DBMS's supported, you may choose to import DDL files or connect directly to the database and reverse the design via ODBC. System Architect provides a number of sample DDL files that you can use to experiment with the Reverse Data Engineer. They represent a database design for a Library System. Let's reverse the sample provided for Oracle, and create a new model in our project for this library system.

1. Select Tools, DB Reverse Engineering. The System Architect Reverse Data Engineer dialog opens.

2. Select Options, Session. Select the More button in the lower right-hand corner of the dialog to expand the selections. These are your import options. You can view them, and reference the on-line help if you have questions. Click OK or Cancel to close the dialog.

3. Select Options, Select Model. 4. Type in the name Library System. This will be the name of

the model that we will import the database design into. 5. Select File, Import DDL File.


15-16

6. Select Oracle 8 as the Import DBMS type. 7. In the Directories list, browse to and select the directory

<C>:\Program Files\Popkin Software\System Architect \RDE Samples.

8. In the File Name list box, select ORA7_LIB.SQL. Click Open. The Set New Diagram Name dialog opens.

9. Type in the name of a new physical diagram: Library System. The reversal will begin. System Architect will ask you through a message box if you'd like to apply aesthetics. Click Yes. The new physical diagram will be created.

Figure 15-6 Specify the SQL or DDL file to import.

Reversing Database Designs

15-17

10. Notice that in the browser, in the Data Modeling tab, you now have two models in this project encyclopedia - one for a hotel reservation system and one for a library system. Each is represented by a combination of logical or physical diagrams. The underlying data dictionary presents a number of shared definition types, including data elements and domains (see the Shared folder).

You could create a logical diagram from this physical diagram (by selecting Dictionary, Create Data Model, Entity Relation), and even take the logical ER diagram and convert it into a UML Class diagram (save the logical diagram, then create a new UML diagram and select Dictionary, Forward and Reverse Code Engineer, then select File, Import, From ER Diagram in the subsequent dialog). These exercises are not in the scope of this tutorial.

Figure 15-7 Viewing the reverse- engineered physical model.

16-1

16 Reporting System

The reporting system can report on all information contained in the project repository (encyclopedia). Pre-written reports are provided, and you may also easily build your own reports with a GUI Report Editor. The GUI Report Editor provides an interface to a SQL-like scripting language, which you may also use via a Text Editor.

This tutorial contains step-by-step instructions on how to run one of the pre-written reports provided, and how to create your own simple report using the GUI Report Editor. This second part of the tutorial, creating your own report, is optional.

This chapter also contains instruction on using the HTML Publishing Tools.

Topics in this chapter Page Opening System Architect Encyclopedia 16-2

Run a Pre-Written Report 16-3

Create a New Report 16-4

HTML Publishing Tutorial 16-22

Introduction

In this Chapter…

Reporting System

16-2

Opening System Architect Encyclopedia To begin, we will open the Samples encyclopedia provided with System Architect (for those of you have taken the previous parts of this tutorial, we are switching to Samples for those users who just want to take the Reporting tutorial).

1. In System Architect, open the Samples encyclopedia (select File, Open Encyclopedia). The Encyclopedia Open dialog appears as shown below.

2. Select the Existing tab and browse to and open

C:\PROGRAM FILES\POPKIN SOFTWARE\SYSTEM ARCHITECT\ENCYCLOPEDIAS\SAMPLES.

3. Click OK to load the samples encyclopedia.

Figure 16-1 Open the Samples encyclopedia.

Run a Pre-Written Report

16-3

Run a Pre-Written Report System Architect's reporting system provides a number of pre-written report files. Each of these report files (.rpt extension) contain a number of prewritten reports.

To run a pre-written report:

1. Select Reports, Report Generator to open the Reports dialog.

2. By default you will open the reports.rpt file, which contains reports in it.

3. Select the report Diagrams contained in the encyclopedia (audit trail), and press the Print button. A print dialog will open. Press OK to print the report.

4. If you are not connected to a printer, or just wish to view a quick view of the report on your screen, press the Draft button. The report will be generated to a dialog on your screen, unformatted.

5. To view other report files, select File, Open Report Files in the Reports dialog. Notice that a number of .rpt files are available for selecting in the <C>:\Program Files\Popkin Software\System Architect \Reports directory. You may open any of these report files (for example, ood.rpt for object-oriented design reports) to view the reports listed in them, and run one.

Viewing Other Report Files

Reporting System

16-4

Create a New Report This section of the tutorial takes you step-by-step through the GUI Report Editor to create a new report file, and a new report within that file. The report that we will create will look at all the Entity Relation diagrams in the currently open encyclopedia, get and print the names of all entity symbols on those diagrams, get each entity symbol's definition, and within that definition get and print their attributes, and each attribute's underlying data element and type.

To build your own report, knowledge of the encyclopedia's metamodel is helpful. We have included a visual representation of how a report queries and accesses the different parts of the encyclopedia for each step in the tutorial.

Create a New Report

16-5

The path through the System Architect encyclopedia metamodel that this particular report takes is shown below.

To create a new report file:

1. Select Reports, Report Generator in the encyclopedia.

2. The Reports dialog opens, and by default lists the reports

in the reports.rpt file.

Figure 16-2 System Architect reporting metamodel.

Create a New Report

Figure 16-3 Open the Report Generator.

Reporting System

16-6

3. In the Reports dialog, select File, New Report File.

You are presented with an empty Reports dialog. You are ready to add a new report.

4. Press the Add button in the Reports dialog to open the Add Report dialog.

Figure 16-4 Create a new report file.

Figure 16-5 Add a new report to the report file.

Create a New Report

16-7

Select the Diagram Type

1. In the Report Name property field, type in Entity Relation

Diagram Report.

Note: Directly below the Description field is the Current Diagram checkbox. This property box, if clicked on, will only query the currently open diagram. For this tutorial we will query the entire Samples encyclopedia, so we will leave the Current Diagram checkbox toggled off.

The report will begin gathering information at the diagram level.

2. In the first drop-down list box, select Diagrams (see diagram below).

3. Note where we are in the metamodel diagram (below right) -- we have just made this report start its query at the diagram level of the encyclopedia metamodel.

Specifying that the Report Starts at the Diagram Level

Figure 16-6 Specify to have the report get diagrams.

Reporting System

16-8

4. Click the Where button to the right of Diagrams to open the Select Diagram Where dialog. Toggle off All Types, and instead select Entity Relation from the list. Click OK.

Figure 16-7 Specify the diagram type as Entity Relation.

Create a New Report

16-9

Select Diagram Properties to Print

We have specified that the report will query Entity Relation diagrams in the encyclopedia. Now let's specify the property or properties to get values for and print for every diagram. At every level of the metamodel, we can specify properties to include in the report (or print). Available properties can be viewed by clicking on the Properties to Print... button at each level.

1. Click on the Properties to Print... button in the Add Report dialog as shown below.

2. The Select Diagram Properties to Print dialog opens.

The properties displayed in the left-hand box are properties contained in the Diagram definition.

3. Select Name from the Available Properties listbox, and click the Add button. Name will be sent over to the Properties to Print listbox.

Figure 16-8 Specify properties to print (report on).

Reporting System

16-10

4. Select Name in the Properties to Print listbox to activate the "Name" Layout property set at the bottom of the dialog. Type in Diagram Name in the Label property box.

5. Click OK to close the Select Diagram Properties to Print

dialog.

Figure 16-9 Relabel the property.

Create a New Report

16-11

Make Report Contain Symbols on Diagram

Now that we have specified the diagram properties portion of the report, we can move to the next portion, which is reporting on the symbols of the diagram.

1. In the second dropdown box, select contain Symbols as shown below.

2. Notice on the metamodel diagram to the right that selecting this relation moves the query from the Diagram portion to the Symbol portion through the contain Symbols relationship.

Figure 16-10 Specify that the report get symbols on a diagram.

Reporting System

16-12

Select Entities As the Symbol Type

Since, for this tutorial, we are only interested in printing Entities on each ER diagram, we will limit the encyclopedia query to just Entities by performing the following steps:

1. In the Add Report dialog, click on the where... button located directly to the right of the contain Symbols choice. You will open the Select Symbol Where dialog, as shown below.

2. Deselect the All Types checkbox and choose Entity in the

Types list box.

3. Click OK to close the Select Symbol Where dialog.

Figure 16-11 Specify that the report get Entity symbols.

Create a New Report

16-13

Select Entity Definition Properties To Print

We now need to get the definition underneath the symbol type that we have chosen.

1. Click on the third drop-down list box in the Add Report dialog. Notice that there are a number of relationship types to choose from. The only way to know the correct one to choose is by looking at and understanding the metamodel diagram below.

2. Notice in the metamodel diagram to the right, that Symbol is defined by Symbol Definition.

3. Select defined by Definitions in the third drop-down list box, as shown below.

4. Click on the where... button directly to the right of the defined by Definitions choice. Notice how the only diagram type available is an Entity Relation diagram, and it is already selected (since by default all diagram types are selected). Click OK to close this dialog.

Figure 16-12 Specify that the report get definitions of symbols.

Select Properties of this Definition Type

Reporting System

16-14

5. Click on Properties to Print, to the right of the defined by Definitions choice, to open the Select Properties to Print dialog.

6. Select Name from the Available Properties listbox, and click the Add button. Name will be sent over to the Properties to Print listbox.

7. Select Name in the Properties to Print listbox to activate the "Name" Layout property field at the bottom of the dialog. Type in Entity Name in the Label property box.

8. Click OK to close the Select Symbol Properties to Print

dialog.

Figure 16-13 Specify that the report get the name of the entity.

Create a New Report

16-15

Select Entity Definition Properties

We now want to query the attributes that belong to Entity definitions. We must add additional levels to our query.

1. In the Add Report dialog, click on the More button in the bottom right-hand corner. The dialog will expand, providing us with more levels to specify items to query.

2. Click on the fourth drop-down listbox and select Use

Definitions in the Add Report dialog. Notice that in the metamodel diagram to the right, below, a symbol definition uses the attribute definition.

Figure 16-14 Expand the Add Report dialog.

Reporting System

16-16

3. In the Add Report dialog, click on the where... button located directly to the right of the drop-down list containing the use Definitions choice. The Select Symbol Where dialog appears.

4. Deselect the All Types checkbox and choose the Attribute item in the or Type(s)= list box as shown below.

Figure 16-15 An entity definition uses an attribute definition.

Figure 16-16 Specify that the report get attributes.

Create a New Report

16-17


6. Click Properties to Print button for the use Definitions level.

7. In the Available Properties list, select Name , hold down your CTRL key on your keyboard and also select PK (primary key). Click the Add button to place the properties in the Properties to Print listbox.

8. Select Name in the Properties to Print listbox to activate the "Name" Layout property set at the bottom of the dialog. Type in Attribute Name in the Label property box.

9. Click OK to close the Select Diagram Properties to Print

dialog.

Figure 16-17 Specify that the report get the name and primary key of each attribute.

Reporting System

16-18

Use "Is A" Relationship

Finally, we want to get at the data element underlying each attribute. We will take a look at the metamodel, and realize an attribute is an instance of a data element -- there is an 'Is a' relationship between them. We will use this relationship to query the encyclopedia for data elements.

1. Click on the fifth drop-down box and select instances of ("is a") Definitions.

2. Click on the where... button directly to the right of the instances of ["is a"] Definition choice. Notice how the only definition types available are Data Elements and Data Structures, and they are already selected (since by default

Figure 16-18 Specify that the report get data elements that are instantiated by attributes.

Create a New Report

16-19

all definition types are selected). Click OK to close this dialog.

3. Click on Properties to Print, to the right of the instances of ["is a"] Definition choice, to open the Select Properties to Print dialog.

4. Select Name and Data Type from the Available Properties listbox, and click the Add button. Name and Data Type are sent over to the Properties to Print listbox.

5. Select Name in the Properties to Print listbox to activate the "Name" Layout property field at the bottom of the dialog. Type in Data Element/Structure Name in the Label property box.

Figure 16-19 Specify that the report get the name and data type of each data element.

Reporting System

16-20

Final Report

The Final Report should now resemble the diagram shown below.

1. To test the report, click on the Draft button. This provides

an on-screen draft preview of the report's contents.

2. To print the report to a printer, click on Print.

3. At the "Save Changes to 'UNTITLED?' " message, click on Yes.

4. Name the new report file Tutorial.rpt. Click on OK.

The report can be modified in the future by choosing the File, Open Report File option of the Reports dialog and opening the tutorial.rpt file.

Figure 16-20 Final Add Report dialog.

Create a New Report

16-21

A report does not have to start at the diagram level. Since relationships are bi-directional (e.g. "contain Symbols" vs. "is contained in"), a report can be written starting at any portion of the encyclopedia and working out. An example of this would be a process diagram having a parent process. To travel from the current process diagram to the parent process, the ‘Is Child’ relationship would be chosen.

Reports can be written to report on the entire encyclopedia (as we have just done for this tutorial) or for the currently open diagram only (by toggling on the Current Diagram checkbox in the upper-left corner of the dialog).

Additional Information

Reporting System

16-22

HTML Publishing Tutorial System Architect's HTML Generator enables you to publish all or some of the diagrams in a project encyclopedia to an HTML format, providing context-sensitive .jpg or .png files of every diagram, with links to pages containing all information of all symbols on the diagram.

In this section of the tutorial, we will generate an HTML document from System Architect encyclopedia.

HTML Publishing Tutorial

16-23

Opening The SA/HTML Generator

To publish HTML, you must have System Architect up and running, and have open the project encyclopedia that you wish to publish HTML from.

1. If it is not currently open, within System Architect, open the Samples encyclopedia. (select File, Open Encyclopedia; select the Existing tab in the Encyclopedia Open dialog, and browse to and open <c>:\Program Files\Popkin Software\System Architect\encyclopedias\Samples.

Reporting System

16-24

2. Select Reports, HTML Reports. This will open the HTML Generator and provide you with the following dialog:

Figure 16-21 HTML Generator dialog.

Select a Template Home Page

16-25

Select a Template Home Page The first thing to do is make sure that the HTML Generator is pointing at the correct Template Home Page.

1. Make sure that the Template Home Page is set to <C>:\Program Files\Popkin Software\System Architect \SAHTML\Template\default.htm (Where <C>:\Program Files\Popkin Software\System Architect is your System Architect program path).

If this is not the case, or if the HTML Generator has been installed to a different path, then the template path may be elsewhere. When the HTML Generator is first run, the Template path is found, however to re-find the Template path:

2. Select the Advanced tab and click on the Default button. This will reset the Template path correctly.

Note: As shipped, the HTML Generator comes with a basic outline template, which has been designed so that you may customize it if you so choose. The template consists of the constant pages of the web site (identified by the extension .HTM) and also the outline definitions of several of the variable (generated) pages (identified by the extension .INC). One of the constant pages must be chosen as the home page, in this example it is 'Default.HTM'. The folder which contains all of the constant pages and home page is known as the 'Template Path'.

Reporting System

16-26

Select the Publish Home Page

The Publish Home Page is the destination home page for the web report that you will generate. It normally has the file name of default.htm. The Publish Path should be an empty folder on a local drive or network. A number of interrelated HTML pages will be generated to this folder, so it is best to begin with an empty folder. (In addition, all files in the Publish path, with names that are used during generation, will be overwritten WITHOUT WARNING.)

1. Within the Publish Home Page text box, use the Browse button to select the path and file name to generate the HTML report to; for example: <C>:\My Documents\Temp\default.htm. (You can create a new directory via the Browse button by clicking on the New Folder button.)

Note: The filename chosen 'Default.htm' is the same as the filename following the Template Home Page path. This is deliberate, as some of the template files have hyper-links to a file called 'Default.htm'. For this reason we do not wish the name of the generated file to be different from the Template filename.


16-27

Selecting Diagrams

Having selected the Template and Publish Home Pages paths, the generator now needs to know which diagrams you wish to publish.

1. Select the Diagrams tab to view the dialog below:

By default, all diagrams are automatically added to the Diagrams for generation list. For this tutorial, we won't generate all diagrams; we will select a few.

2. Click the button to remove all the diagrams listings into the Source List box.

Note: An alternative way to move all of the diagrams from the Diagrams for Generation list to the Source List is to click the Clear button and then click the Search button.

Let's now select some Use Case diagrams to publish.

Figure 16-22 Diagrams tab of HTML Generator.

Reporting System

16-28

3. In the Type drop-down list box, select Use Case and click on the Search button. Only diagrams of type Use Case are displayed in the Source List.

4. Hold down the CTRL key on your keyboard, and in the Source List box select:

� Hotel Reservation Use Case Context (Use Case)

� Make Reservation (Use Case)

5. Click on the to bring the selected diagrams from the Source List to the Diagrams for generation list box.

6. Make sure the Maximum diagram width property is set to

a value of (or above) '1024'. We are now ready to publish the diagrams.

Figure 16-23 Select diagrams to publish.


16-29

Generate HTML

Having selected a Template Home Page, a Publish Home Page and the diagrams to generate, we are now ready to publish our design to HTML format.

1. Press the Publish button (viewable from any tab). The HTML Generator will present you with a dialog warning you that HTML will create (and potentially overwrite) files and directories in the path you chose.

2. Select OK to proceed. The HTML Generator will present you with the following dialog as it publishes:

� The top panel (underlined in light blue) details the main task or diagram to be processed.

� The middle panel (underlined in green) details a sub task of the main task.

� The Progress bar (underlined in yellow) gives an indication of when the generation is completed.

Note: When definitions are selected to be generated, there will always be two passes. The first pass, gets all of the definitions and processes the diagrams. The second pass processes the definitions. The more diagrams you select, the longer it will take the generator to publish.

Anytime during the generation process it is possible to abort the run by clicking on the 'Cancel' button. The generator will stop at the next convenient moment.

Figure 16-24 Generation-in-progress dialog.

Reporting System

16-30

View the Results When the HTML report is complete, you are presented with a Generation Complete dialog. The HTML Generator will load the generated files with your Internet browser, allowing you to browse the report.

Figure 16-25 Final published report.