cours slides

UML in practice : Modeling with IBM Rational Software Architect, V7

Module 0 : About This Course

0 - 2

Intended Audience

The intended audience for this course is software developers who architect and develop enterprise applications, and who:

Use the Unified Modeling Language (UML) for object-oriented analysis and design (OOAD)

Develop Java™ applications and DB

Apply design patterns in their system design

Work as part of a team of developers

0 - 3

Course Goals and Objectives

After completing this course, you will be able to perform the following tasks with IBM® Rational® Software Architect:

Navigate the user interface and create perspectives

Create new UML Model projects

Create structural and behavioral UML diagrams

Compare, merge, combine, and publish diagrams

Apply patterns and transformations Java and DB

Create traceability to IBM® Rational® RequisitePro® and IBM®WebSphere® Business Modeler

RUP (Rational Unified Process)

0 - 4

Course Agenda

Module 0 : About This Course

Module 1 : Getting Started with Rational Software Architect

Module 2 : Model Structure and Templates

Module 3 : Creating UML Diagrams

Module 4 : Creating UML Diagrams of System Structure

Module 5 : Creating UML Diagrams of System Behavior

Module 6 : Team Development

Module 7 : Patterns, Transformations, and Visualization

Module 8 : Traceability, Model Querying, and Model Validation

Module 9 : Dexis Case with UML

Module 10 : CARSID Case with RUP


Module 1 : Getting Started with Rational Software Architect

1 - 2

Module Objectives

After completing this module, you will be able to:

Describe the underlying framework behind all IBM®Rational® Software Delivery Platform tools.

Navigate the basic user interface of any IBM Rational Software Delivery Platform tool.

Create, modify, and save a Perspective

Create and modify a Project

Describe the basic purpose of Rational Software Architect

1 - 3

The IBM Rational Software Delivery Platform The IBM Rational Software Delivery Platform is a complete solution for developing software and software-based systems.

Most platform tools are based on the Eclipse framework, which:

Simplifies development

Integrates the enterprise environment

Unifies technologies into a single development environment

Delivers flexibility and choice

1 - 4

What is Eclipse?

Eclipse is a platform for building, deploying, and managing software across the lifecycle.

The Eclipse platform encourages rapid development of integrated features based on a plug-in model.

The Eclipse platform user interface is featured in all IBM Rational Software Delivery Platform tools.

1 - 5

The WorkspaceWhen you open any tool in the IBM Software Delivery Platform for the first time, you will see the Workspace Launcher dialog.

A workspace is the location where you store your work.

Any resources (projects, folders, and files) that you are working on are available in this workspace.

The workspace itself is a directory, which defaults to the name workspace. You may locate it anywhere you want. It may contain either new projects as sub-directories, or just references to projects that exist elsewhere on the file system.

The workspace itself is a directory, which defaults to the name workspace. You may locate it anywhere you want. It may contain either new projects as sub-directories, or just references to projects that exist elsewhere on the file system.

1 - 6

The Welcome View

Basic User Interface: The Welcome ViewAfter the workspace dialog, the Welcome view will be the first thing you see.

OverviewGet an overview of the features

OverviewGet an overview of the features

What’s NewFind out what is new

What’s NewFind out what is new

SamplesTry out the samples

SamplesTry out the samples

TutorialsGo through tutorials

TutorialsGo through tutorials

WorkbenchGo to the workbench

WorkbenchGo to the workbench

Note: You can get the Welcome view back at any time by selecting Help > Welcome.Note: You can get the Welcome view back at any time by selecting Help > Welcome.

Web ResourcesRead more on the web

Web ResourcesRead more on the web

MigrateMigrate to the new release

MigrateMigrate to the new release

First StepsMake first steps

First StepsMake first steps

1 - 7

The Workbench

Basic User Interface: The WorkbenchThe workbench acts as a hub for identifying all of the plug-in functions. Each workbench offers one or more perspectives, which contain views and editors to display information.

In the workbench you can navigate resources, as well as view and edit the content and properties of these resources.

A shortcut bar appears in the top right corner of the window. This allows you to open new perspectives and switch between ones already open.

The name of the active perspective is shown in the title of the window, and is highlighted in the shortcut bar.

A shortcut bar appears in the top right corner of the window. This allows you to open new perspectives and switch between ones already open.

The name of the active perspective is shown in the title of the window, and is highlighted in the shortcut bar.

1 - 8

PerspectivesA perspective defines a set of editors and views arranged in an initial layout for a particular role or task.

For example, the initial layout of the Resource perspective makes the Navigator view and editor visible, and arranges them in a default layout. The default set of views is different for each of the perspectives.

You can open the workbench to any of several perspectives, or you can define your own perspective. Different perspectives are better suited for different user tasks. Common perspectives include:

Resource The default perspective of most tools

JavaFor working with Java projects

CVS Repository ExploringFor checking projects in and out securely

Java Browsing For browsing the structure of Java projects

DebugFor debugging a program

Plug-In DevelopmentFor developing Eclipse plug-ins

1 - 9

Views and Editors

A view is used to navigate a hierarchy of information (such as the resources in the Workbench), open an editor, or display properties for the active editor.

The Navigator View provides a hierarchical view of resources and allows you to open them for editing.

An editor is used to edit or browse a resource.

An editor or view that is active is the one whose title bar is highlighted. Here, the Navigator view is active.

An editor or view that is active is the one whose title bar is highlighted. Here, the Navigator view is active.

1 - 10

EditorsEditors allow document editing from within the workbench for various types of artifacts, including text and diagrams.

The name of the file appears in the tab of the editor. If an asterisk (*) appears at the left side of the tab, this indicates that the editor has unsaved changes.

The name of the file appears in the tab of the editor. If an asterisk (*) appears at the left side of the tab, this indicates that the editor has unsaved changes.

Several editors can be open at the same time, but by default are stacked in the user interface. You can arrange them to make more than one visible at a time.

Several editors can be open at the same time, but by default are stacked in the user interface. You can arrange them to make more than one visible at a time.

1 - 11

Projects

A project is a collection of any number of files and folders. It is a container for organizing other resources that relate to that project.

Projects are used for builds, version management, sharing, and resource organization.

The New Project wizard helps you create a new C or C++ project in the workbench. To access the wizard, select File > New > Project from the menu.

The New Project wizard helps you create a new C or C++ project in the workbench. To access the wizard, select File > New > Project from the menu.

1 - 12

Importing and Exporting ProjectsYou can use the Import wizard to import a project that exists in a different workspace, or one that previously existed in a workspace, into the Workbench.

The Import wizard can be accessed from the main menu bar: select File > Import.

1 - 13

Lab 01: Creating a Project

In this lab, you will learn how to create a new project, a folder within the project, and two files within that folder.

After completing this lab, you will be able to:

Create and use resources

Manipulate the user interface

To begin the lab:

In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.

Click Select a Cheat Sheet from the list.

Expand DEV396 Labs, then select 01 Create a Project.

Follow the directions indicated on the Cheat Sheet.

The instructor will walk through this lab together with the class in order to demonstrate cheat sheet navigation.

The instructor will walk through this lab together with the class in order to demonstrate cheat sheet navigation.

1 - 14

Help

There are extensive Help resources that include:

Help Contents

Tips and Tricks

Cheat Sheets

Dynamic Help

1 - 15

Cheat Sheets

The exercises included with this course will be performed in Cheat Sheets. Cheat sheets provide an interactive lab environment within the application we are exploring.

Cheat Sheets save the student time by:

Having the lab steps in place beside the work being done

Not having to retype content

Allowing steps to be repeated

Automating the loading of lab input artifacts

Cheat Sheets assists the student in learning by:

Integrating with multimedia

Allowing you to take the cheat sheets of interest and install them in your own instance of the product, for later reference and guidance

1 - 16

Lab 02: Customizing PerspectivesIn this lab, you will work with multiple instances. You will begin by customizing a perspective, and then make it the default perspective.

After completing this lab, you will be able to:Customize a perspective

Open multiple windows and workspaces

To begin the lab:



Expand DEV396 Labs, then select 02 Customize Perspectives.


1 - 17

Rational Software Architect: For Architects and Developers

For software architects who need to:

Model applications

Enforce architectural and coding standards

Develop and apply patterns and transformations

For software developers who need to:

Develop using models and code

Review code against coding standards

Apply patterns and transformations

For all who develop as part of a team

1 - 18

Model-Driven Development in Rational Software Architect

Create the domain model

Create the use-case model

Create the design model

Complete the implementation using UML visualization

Transformation

Transformation

Transformation

Traceability relationships created as a byproduct of patterns and transformations


Module 2 : Model Structure and Templates

2 - 2

After completing this module, you will be able to:Locate and use the Modeling perspective and viewsCreate and organize projects and models in Rational Software ArchitectCreate Models based on Model templates

Module Objectives

2 - 3

What is a Model ?

A model is a semantically closed abstraction of a subject system.

The RUP methodology defines a model as a complete description of a system from a particular perspective.

Examples of models:UML modelCodeData model

2 - 5

A UML model is only one type of model, which is used for:Specifying structure, behavior, or bothVisualizing an existing system to improve understandingAutomating system development (Model-Driven Development)

UML Models in Rational Software Architect:

A resource (.emx)Logical model, the contents of a model file

What is a UML Model in Rational Software Architect ?

Physical Model File

(Logical) Model

Closed modelClosed model

Open modelOpen model

Model files in a UML Modeling project as shown in the Navigator view.

Model files in a UML Modeling project as shown in the Navigator view.

2 - 6

Comments

In the RUP methodology, a model is defined as a complete specification of a problem or solution domain from a particular perspective. A UML (Unified Modeling Language) model is just one of many types of models used in software development. UML models help the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as the UML, different members of the development team can communicate their decisions unambiguously to one another.You can use UML models to represent a system that you want to build visually; to build a common understanding of a system; to develop, verify, and communicate a system’s architecture; and to generate code. UML model files in Rational Software Architect contain model elements (such as actors, use cases, and classes, and packages, relationships, and associations), and one or more diagrams.In addition to these objects, models contain UML profile information, user preferences, and workspace information.A modeling project can contain any number of models. You can open and manage each model in the Project Explorer view, and you can open diagrams from more than one model at the same time.Note that the main file types used in Rational Software Architect are :

File Type ExtensionUML Model .emxUML Model Fragment .efxUML Profile .epxClass Diagram .dnxTopic Diagram .tpxObject Constraint Language (OCL) resource .oclTransformation Configuration .tcReusable Asset .rasRAS Manifest .rmd

2 - 7

The Modeling Perspective

The Modeling Perspective contains the tools needed to build UML models and diagrams.

Editors

Views

2 - 8

Comments

The Rational Software Architect workbench window contains one or more perspectives. A perspectivedefines the initial set of content editors and related views (used to navigate information in the editor), and their layout in the workbench window.

Perspectives gather together sets of features for specific development activities. For example, the Javaperspective gathers tools for writing code: the Package Explorer, Problems view, Outline view, and Java editor.

The Modeling Perspective contains the tools needed for building UML models and diagrams, including the diagram editor, with the following views: Project Explorer view, Pattern Explorer, Outline view, Inheritance Explorer, Properties view, Tasks view, Output window, and Bookmarks view.

2 - 9

Views in the Modeling Perspective

Views in the ModelingPerspective:

For exploring modeling projects:

Project Explorer view– Diagrams– Models

For exploring resources:Pattern Explorer viewOutline viewInheritance Explorer viewProperties view

For getting feedback:Tasks viewOutput window

2 - 10

Comments

Views are windows that provide different ways to navigate the information in the workspace and in the workbench. For example, the Project Explorer view displays projects and models you are working with. A diagram in the Project Explorer view can be opened into the diagram editor. The properties of the selected diagram can be modified in the Properties view.

A view might appear by itself, or stacked with other views in a tabbed notebook. You can change the layout of a perspective by opening and closing views, and by docking them in different positions in the Workbench window.

2 - 11

Project Explorer ViewUsed for navigating and organizing models.

Class

Attribute

Diagram

Relationship

Package

Diagram

Open Model

Closed Model

2 - 12

Comments

Under each model file, the Project Explorer view displays the logical structure of the model, including the name of the model and any packages, diagrams, relationships, and other model elements it contains. The model icon (light brown, containing a triangle) inside the model file allows you to add model elements at the root level of the model, and it allows you to set certain properties for the model.

You can use the Project Explorer view to add, delete, move, organize, and sort model elements for each model in your project.

2 - 13

Properties ViewDisplays properties and values for the selected element.

2 - 14

Comments

All models, diagrams, model elements, and relationships have associated properties, just like all other project resources.

In the Modeling Perspective, properties are organized into a series of tabbed categories. Most model elements contain the following categories:

• General: Includes the name of the elements, qualified name, keywords for searches, visibility, and an option to make the element abstract.

• Documentation: Used for adding documentation to model elements.

• Advanced: Displays an Eclipse-style properties page.

2 - 15

Diagram Editor

Drawing Surface

Tools

Palette

Drawers

2 - 16

Comments

The diagram editor contains both the drawing surface and the toolbox. The toolbox contains a basic set of tools (available by default) for selecting and annotating shapes in the diagram, along with one or more drawers of tools for various diagram types. You can customize the look and behavior of drawers in the toolbox, as well as create and customize your own drawers.

2 - 17

Outline ViewWhen the diagram editor is open, the Outline view can show either:

A thumbnail graphical view of the diagramA tree view listing the elements of the diagram

2 - 18

Comments

The Outline view displays an outline of the structured file that is currently open in the editor area, and lists its structural elements.

The contents of the Outline view are editor-specific. When the diagram editor is open, the Outline view can show either:

• A tree view listing the elements in the file open in the editor area (upper-right icon named Outline)

• A thumbnail of the diagram (upper-right icon named Overview) with the screen area dimmed (in gray). In the screenshot, the Overview icon is selected, thus showing a graphical thumbnail of the diagram. You can move the active screen area in the outline view to navigate the diagram.

2 - 19

UML Model Editor

2 - 20

Comments

The UML Model editor appears every time you open a model. To close your model, close the UML Model editor. From the UML Model editor, you can add documentation to the model and navigate to specific diagrams in the model. It also provides the following model information:

Overview• Alerts and Action Items: Lists problems associated with this model• General Information: Provides general model file properties, including name, location in the workspace,

size of the file, modify date, and read or write status• Documentation: Allows you to add documentation at the model level, just the way you would document

an element in a model

Details• Applied Profiles: Shows which UML profiles are currently applied to the model. Applying profiles makes

available sets of stereotypes that extend the UML to create specialized models.• Diagrams: Lists diagrams in this model• Model Libraries: Model libraries imported by this model

References• Referenced Models: Shows the models that the open model references. A referenced model contains

model information from a referenced component or project.

Fragments: Lists fragments of this model

2 - 21

Rational Unified Process Resources

Process guidance is built in the:

Rational Software Architect Process Advisor featureRational Software Architect Process Browser feature

These resources can guide you in determining what models and diagrams you need.

2 - 22

Comments

The RUP platform is a software engineering process and an industry-wide platform for best practices. There is a configuration of the RUP methodology designed especially for Rational Software Architect users, one which is accessible in two features in Rational Software Architect:

Process Advisor: The Process Advisor is a view that presents context-sensitive references to RUP Tool Mentors, Artifacts, and Activities. From this view you can also search the RUP product and access Help.

Process Browser: The RUP Process Browser in Rational Software Architect is a separate window that opens to display the RUP content selected in the Process Advisor view. It also allows you to browse the RUP product.

2 - 23

Rational Software Architect Project Types

There are two basic types of projects.

UML projects:For pre-implementation models

Blank or based on a model template

Implementation projects:Java, EJB™ (Enterprise JavaBeans™) technology , and so on

Implementation projects can contain UML class and sequence diagrams

Simple projects can be of either type. New Project wizard

Java Project

Simple Project

UML Project

2 - 24

Comments

A project in Rational Software Architect is just a container for resources, such as model files, code files, HTML or XML files, and so on.

In Rational Software Architect, you will develop two types of projects: UML projects for pre-implementation models, and implementation projects, in which the code is the implementation model. Implementation projects can contain free-standing UML class and sequence diagrams, which you can use to visualize the code’s structure and runtime behavior.

A Simple project is an empty project folder, which you can populate with any file structures and resources.A UML project is a Simple project that contains a model file. You can either create blank models or ones based on a Rational Software Architect UML model template.The following implementation projects are available in Rational Software Architect:

Enterprise: An enterprise application project contains the hierarchy of resources required to deploy a J2EE enterprise application, often referred to as an EAR file.

EJB: EJB (Enterprise JavaBeans™) projects include the resources contained in an EJB module.

Web: Web projects are used for creating dynamic Web applications and static Web sites. Dynamic Web projects provide an accompanying EAR project.

Connector: A connector is a J2EE standard extension mechanism for containers that provides connectivity to enterprise information systems (EISs).

2 - 25

Model Templates in Rational Software Architect

UML Project templates are available in the New Project wizard. The following model templates are available:

Analysis ModelBlank ModelCORBA Template ModelDoDAF ModelEnterprise IT Design ModelService Design ModelUse Case ModelXSD Model

2 - 27

UML ProfilesUML profiles are often included with module templatesProfiles provide a mechanism for extending the UML without having to change the modeling language itself.Profiles include:

Stereotypes: A simple textual marker («…») or icon placed on a model element to add semantics to the elementTagged values: To add properties that are not supported by the base elementConstraints: Constraints enforced on the element or its attributes

2 - 28

Comments

A UML profile identifies a particular subset of model elements and defines stereotypes and constraints that can be applied to it. The stereotypes that are contained in a profile can be used when a profile is applied to a UML model.

• Stereotype: A simple textual marker («…») or icon placed on a model element to add semantics to the element. A stereotype extends UML, but not its structure. You can add stereotypes to model elements to create specialized forms, but you cannot add new elements to UML.

• Tagged Values: Typically a string or Boolean value, tag definitions can be associated with specific stereotypes or with all model elements of a specific type (class, association, operation parameter, and so on). Tagged values used to add values to model elements, similar to metadata, and used very often to add information for transformations and code generation.

• Constraint: A set of rules that can be executed to determine a model or modeling element’s correctness. Constraints are usually defined using the Object Constraint Language (OCL), but can also be defined in natural languages and Java.

In the Rational Software Architect tool, the UML 2.0 Base, Intermediate, and Complete profiles are automatically applied to every UML model. The tool also provides the Deployment profile and the Default profile, both of which are also automatically applied to every UML model.

Two key best practices for working with profiles in multiple models are:• Keep platform-independent content and platform-specific content separate, in different logical (top-level)

models.• Maintain cross-model relationships in the platform-specific models.

2 - 29

How Are Profiles Used ?

Profiles are used to model platform-or model-specific abstractions, for example:

Enterprise beansAnalysis classes

Profiles provide a domain-specific language for reusable assets:

Add to model templatesUse with domain-specific patternsUse a transformation to create a platform-specificmodel

Custom profiles can be created in Rational Software Architect and shared with other users

Profile

Model Template

Patterns

Designed to recognize andtransform elements with stereotypesfrom the profile.

May include parameters with stereotypesfrom the profile. Patterns can be used to add stereotypes to model elements.

Profile added to the template and modelscreated from it. Elements in the model can have stereotypes from the profile, with constraints ensuringcorrect usage.

Transformations

2 - 30

Comments

Rational Software Architect allows you to develop and apply UML profiles that you can use to create model elements that reflect the semantics of a specific domain or platform, or for a particular model. For example, the RUP Analysis model template is supported by the Analysis profile, which provides «Boundary», «Entity», and «Control» stereotypes.

Profiles are not just used for modeling, however. They are also used for automating modeling and model transformation using patterns. Design patterns in Rational Software Architect can be used to apply stereotypes to model elements, which are then recognized by transformations run on them so that they can be realized by technology- or platform-specific implementation code.


Module 3 : Creating UML Diagrams

3 - 2

After completing this module, you will be able to:Create UML Diagrams

Diagrams in UML models

Query diagrams

Visual development diagrams

Describe how UML elements can be added to diagrams using:

Action Bars

Tool palette

Project Explorer view

Module Objectives

3 - 3

UML Diagrams in Rational Software ArchitectA model element appears in zero or more diagrams

Diagrams graphically depict a view of a part of your model or codeDifferent diagrams represent different views of the system that you are developing

3 - 4

Comments

In Rational Software Architect, you can open and add diagrams to the model in the Project Explorer view.

A UML project has two main packages that show different views of diagrams in the model. The Models package shows diagrams in their logical place within the model, the Diagrams package shows only the diagrams in the model, spelling out the paths of their locations.

UML diagrams can help system architects and developers understand, collaborate on, and develop an application. High-level architects and managers can use UML diagrams to visualize an entire system or project, and separate applications into smaller components for development.

System developers can use UML diagrams to specify, visualize, and document applications, which can increase efficiency and improve their application design. UML diagrams can also help identify patterns of behavior, which can provide opportunities for reuse and streamlined applications.

The visual representation of a system that UML diagrams provide can offer both low-level and high-level insight into the concept and design of an application.

3 - 5

UML Diagrams in Rational Software Architect

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams

CommunicationDiagrams

State MachineDiagrams

ComponentDiagrams

CompositeStructureDiagrams

ClassDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

Use-CaseDiagrams

3 - 6

Comments

Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models.

Structural DiagramsRational Software Architect allows you to create the following structural diagrams:

• Class diagrams to illustrate logical structure

• Object Diagram to show objects that are instances of classes

• Composite Structure diagrams to show the internal structure of a class or component at runtime

• Component diagrams to illustrate the organization and dependencies among modular parts of the system

• Deployment diagrams to show the mapping of software to hardware configurations

Behavioral DiagramsRational Software Architect allows you to create the following behavioral diagrams:

• Use-Case diagrams to illustrate user interactions with the system

• Activity diagrams to illustrate flows of events

• State Machine diagrams to illustrate the series of states an object can have

• Communication diagrams to illustrate behavior in terms of how objects interact

• Sequence diagrams to illustrate behavior in terms of the sequence of interactions between objects

3 - 7

Creating UML Model DiagramsUse diagrams to represent different views of the system or application:

UML diagramsNon-UML (freeform) diagrams

Create diagrams in:

ModelsModel elements

PackagesComponentsActiveclassesAnd so on

Creating a diagram in the Project Explorer view.

3 - 8

Comments

You can add UML diagrams to models to represent different views of a system. To provide more detail about a specific model element, you can also add one or more diagrams to an element, such as a package, component, or state machine.

For more informal and informational modeling, Freeform diagrams are available. Freeform diagrams allow you to add any element, including the non-UML geometric shapes available in Rational Software Architect.

3 - 9

Review: Diagram Editor

Drawing Surface

Tools

Palette

Drawers

3 - 10

Comments

The diagram editor contains both the drawing surface and the toolbox. The toolbox contains a basic set of tools (available by default) for selecting and annotating shapes in the diagram, along with one or more drawers of tools for various diagram types. You can customize the look and behavior of drawers in the toolbox, as well as create and customize your own drawers.

3 - 11

Adding Model Elements to a Diagram

1Drag an existing element from the Project Explorer view.

Drag an existing element from the Project Explorer view.

+

2Click a tool in the diagram editor’s tool palette and then click inside the diagram.

Click a tool in the diagram editor’s tool palette and then click inside the diagram.

Hover or click the mouse in the diagram to make the action bar appear. Select the element to insert. Hover over the new model element to use the action bar to add details (attributes and operations).

Hover or click the mouse in the diagram to make the action bar appear. Select the element to insert. Hover over the new model element to use the action bar to add details (attributes and operations).

3

3 - 12

Comments

To display elements in the Project Explorer view on an open diagram, just drag them on to the diagram surface. To add new model elements (shapes) using the diagram, you can either click an item in the tool palette and click in the diagram, or click the diagram surface and using the action bar to add items and compartment items.

Although it is not shown in the slide, you can also add shapes to the model by right-clicking the diagram surface and then clicking Add UML and selecting the appropriate shape.

3 - 13

Deleting from the Diagram and the Model

Delete from DiagramRemove the item from the diagram, but do not delete it from the model

Delete from ModelRemove the item from the diagram and the model

Deleting an Element in the Diagram Editor

3 - 14

Comments

You can delete UML model elements from models in the Project Explorer view, and diagrams in the diagram editor. Just right-click the item and click the appropriate delete option :

• Deleting elements from a diagram (using the context menu or Delete key) removes the elements from the diagram, but leaves them in the model.

• Deleting diagram elements from a model (using the context menu) removes the element from the diagram and model.

Note that deleting a model element can be undone (with Edit > Undo or by pressing CTRL-Z), but deleting a diagram from a model is permanent.

3 - 15

Diagram Validation: Validating Model SemanticsExamine a model or diagram for broken semantic rules according to the model's language and constraints:

Confirm adherence to UML requirements, logic, structures, and usage

Click Run Validation on the Modeling menu to validate all open models

3 - 16

Comments

At any time during the construction of a model or a UML diagram, you can check that it is compliant with the defined constraints and ensure that no broken cross-model references exist.

You must have a model open in the Modeling perspective, and you must enable at least one constraint category in the Validation preferences.

In Validation preferences, you can apply constraints defined by the UML 2.0 specification, , as well as the UML 2.0 metamodel constraints that support the usability of specific modeling functions.

To validate a model, diagram, or model element, right-click the item and then click Run Validation. Any violations are listed in the Problems view.

After you validate a model or UML diagram, you can view the validation errors and warnings.

3 - 17

Lab 3: Create UML Diagrams

Complete the following tasks:Task 1: Create a new diagramTask 2: Add shapes and connectorsTask 3: Delete from the diagram and the modelTask 4: Validate the model

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.


Expand DEV396 Labs, then select Lab 3: Create UML Diagrams.


3 - 19

UML Visual Development

Visualize Java and C++ code in UML diagramsVisualize code with diagrams that are either:

Project resourcesClass (.dnx)

Sequence (.tpx)

New diagrams in an existing model (.emx)

Class

Sequence

Freeform

Topic

3 - 20

Comments

You can use UML diagrams to visually represent and develop artifacts of Java and C++ applications in a single, tightly integrated development environment.

You can use UML diagrams to represent and analyze an existing system to identify the system’s components and interrelationships, and to create representations of the system in another form. You can use UML diagrams to automatically abstract the system’s structural information from code to a new form at a higher abstraction level. You can redesign the system for better maintainability, or to produce a copy of a system without access to the design from which it was originally developed. You can also modify the target system, or develop and generate new systems.

A UML class diagram depicts some or all of the components (or elements) in an application. You can use class diagrams to visually represent and develop the structures and relationships for Java classes and interfaces. You can create your own context to understand, collaborate, and develop an application by using a subset of its classes. You can also develop Java elements directly from class diagrams. You can use UML sequence diagrams to visually represent and develop the behaviors and interactions of Java applications, or to visually represent Java methods.

You can use temporary, non-editable browse diagrams to create quick static views and explore existing relationships in applications, and use non-editable topic diagrams to create dynamic views of applications based on context and queries.

You can also generate Javadoc HTML documentation with UML diagram images to provide more information about the source code.

3 - 21

Class Diagrams

Add class diagrams to a Java or C/C++ project to visualize and edit classes.

Code changes automatically update the diagram, and vice versa, when resources are saved.Harvest visualized elements into a model.

3 - 22

Comments

You can create new class diagrams and populate them with Java classes to examine structures and relationships within an application.A class diagram depicts some or all of the classes and interfaces in an application. You can create your own context to visually represent an application by using a subset of its classes and interfaces. You can use class diagrams to develop Java packages, classes, and interfaces and to design their structures and relationships.

3 - 23

Sequence Diagrams

Use sequence diagrams to understand and develop behaviors and interactions among source elements.

Visualize behavior or add and edit lifelines, messages, and combined fragments

3 - 24

Comments

You can use sequence diagrams to create a graphical representation of the source elements in a system or application, in order to understand and develop behaviors and interactions between classes and data types. Create new sequence diagrams, populate existing sequence diagrams with source elements, and add lifelines, messages, and combined fragments to sequence diagrams.

Static UML sequence diagrams can show disruptable interaction operators. A disruptable interaction operator indicates that the interaction fragment represents an exception handling block in the source code (that is, a Java try or catch block). The code in the first operand of this fragment represents the attempted code (the try block). Subsequent operands represent any exception handling blocks.

Optionally, if present in the source, the final operand that is guarded by the condition finally represents code that is executed regardless of whether or not an exception has occurred.

A static UML sequence diagram view is a topic diagram, which has a .tpx file name extension. You can refresh static sequence diagram views of Java methods to reflect the latest changes in the source code. You can convert them to editable UML sequence diagrams (which have a .dnx file name extension) that you can use to understand and develop behaviors and interactions between Java classes and interfaces.

To create a static sequence diagram of a Java method, in the Package Explorer view, right-click a Java method, then click Visualize > Add to New Diagram File > Static Method Sequence Diagram.Note: You can also create static sequence diagram views of Java methods from class, topic, or browse diagrams: right-click a method in a Java class or interface, then click Navigate > Open as Interaction.

3 - 25

Query Diagrams: Topic and Browse

Use topic and browse diagrams to explore relationships in UML models or in code.

With Topic diagrams, you can:Query the model to see a specific set of relationships between agroup of elements from across the model or code

Capture a snapshot of the current state of a model or code

Create an edit diagram based on the topic diagram

With Browse diagrams, you can:Explore relationships from a selected element to other elements

Navigate the model or code

Generate an edit diagram from a browse diagram

3 - 26

Comments

Information in your model that might not be worth formally displaying in diagrams might still have to be managed as part of the model. Such information is better accessed using query (topic and browse) diagrams, so that the information can be found just when needed. For example, rather than maintaining diagrams depicting traceability relationships, set up the relationships in the model and then use querying to find the relationships when needed. This approach can help avoid cluttering models.

Topic and browse diagrams, both of which are not editable and so are not used for modeling, can also be used to analyze and familiarize yourself with an unfamiliar model as part of research. Topic diagrams can be saved or converted into UML class diagrams in the model. Browse diagrams are designed to provide a quick and convenient means of exploring the model, so they are never saved.

3 - 27

Browse DiagramsBrowse diagrams can be used to:

Show the elements related to the selected elementShow the dependencies to the selected elementGain a detailed understanding of the element in focus

Browse diagrams are driven by parameters and filters that you control.

Select relationships to display and levels of relationships, and then click Apply.

Select relationships to display and levels of relationships, and then click Apply.

Right-click the diagram surface and click File > Save As to save the diagram as an edit diagram or image file.

Right-click the diagram surface and click File > Save As to save the diagram as an edit diagram or image file.

Double-click an element in the diagram to make it the focus of a new browse diagram.

Double-click an element in the diagram to make it the focus of a new browse diagram.

3 - 28

Comments

A browse diagram is a temporary diagram in which you can explore the details of a model and its underlying elements and relationships. A browse diagram provides a view of a context element that you specify, and is similar in functionality to a Web browser. You cannot add or modify the individual diagram elements or save a browse diagram in a model. However , you can convert a browse diagram to a freeform modeling diagram in an open model file, or save it in an image file that captures the inheritance hierarchy (which you can send in an e-mail message or publish on a Web site).

To create a browse diagram:

1. In the Project Explorer, right-click a UML or Java element.2. Select Visualize > Explore in Browse diagram.

3 - 29

Lab 4: Create Browse and Topic Diagrams

Complete the following tasks:Task 1: Import Java projectTask 2: Visualize Java code in a Browse Diagram viewTask 3: Visualize Java code in a Topic Diagram view

To begin the lab:



Expand DEV396 Labs, then select Lab 4: Create Browse and Topic Diagrams.



Module 4 : Creating UML Diagrams of System Structure

4 - 2

Module Objectives


Identify the Structural UML diagrams that are available

Identify UML notation, and provide a basic explanation of UML semantics

Create Class, Composite Structure, Component, and Deployment diagrams

4 - 3

Structural UML Diagrams

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams



ComponentDiagrams


ClassDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

Use-CaseDiagrams

4 - 4

Comments

Rational Software Architect allows you to create the following structural diagrams:


• Object Diagram to show objects that are instances of classes

• Composite Structure diagrams to show the internal structure of a class or component at runtime



4 - 5

Class Diagrams

Class diagrams show the classes of the system, their interrelationships, and the operations and attributes of the classes.

Class diagrams are used for a wide variety of purposes, including both conceptual (domain) modeling and detailed design modeling.

4 - 6

Comments

A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.

A class is an abstraction in that it :

• Emphasizes relevant characteristics.

• Suppresses other characteristics

4 - 7

Class Icon

Template Class ParameterTemplate Class ParameterClass NameClass Name

4 - 8

Comments

The class Icon provides compartments for name, attributes, and operations. These compartments can be removed from a diagram if desired.

A number of standard stereotyped classes are available in Rational Software Architect :

• Type: A class that specifies a domain of objects

• ImplementationClass: The implementation of a class in a programming language

• Utility: A class that has no instances, but rather a collection of non-member attributes and operations that are class scoped

• Metaclass: A class whose instances are also classes

• Realization: A classifier that specifies a domain of objects, and its physical implementation

• Specification: A classifier that specifies a domain of objects, without defining a physical implementation

• Focus: A class that specifies the core logic or control flow for one or more auxiliary classes

• Auxiliary: A class that supports a central or fundamental class

4 - 9

Other Class Diagram Model ElementsSignal

A signal is a specification of a send request instance communicated between objects

Enumeration

A data type whose literal values are enumerated in the enumeration

Data Type

Typically data types represent primitive types (such as integer or string types), and enumerations (such as user-defined data types)

Artifact

The specification of a physical piece of information that is used or produced in the software development process

Collaboration

Type of structured classifier in which roles and attributes co-operate to define the internal structure of a classifier

4 - 10

Class Relationships

Class diagrams may contain the following relationships:

Association

Aggregation

Composition

Generalization

Dependency

Realizes

OR

OR

OR

4 - 11

AssociationSpecifies peer-to-peer relationships between model elements

Navigability can be unidirectional or bidirectional

OR

4 - 12

AggregationUsed to model a whole to part relationship between model elements

The part element can exist without the whole


OR

4 - 13

CompositionAggregation with strong ownership

When the container is destroyed, all of its composite objects are destroyed


OR

4 - 14

Generalization

A relationship where one class shares the structure and behavior of one or more classes

Defines a hierarchy of abstractions where a subclass inherits a superclass

This is an “is a kind of” relationship

4 - 15

Dependency

A relationship in which one class uses another

Dependencies may exist between classes because:

A message is sent from one class to the other

One class is part of another's data

One mentions the other as a parameter to an operation

4 - 16

Realization

A specialized relationship where the client implements the suppliers specification

4 - 17

Lab 05: Create a Class Diagram

Complete the following tasks:Review Class Diagram BasicsCreate a New Class DiagramChallenge Yourself

To begin the lab:



Expand DEV396 Labs, then select 05 Create Class Diagrams.


The instructor will walk through this lab together with the class in order to Demonstrate cheat sheet navigation.

The instructor will walk through this lab together with the class in order to Demonstrate cheat sheet navigation.

4 - 19

Object Diagrams

An object diagram shows a complete or partial view of the structure of a modeled system at a specific point in time

This snapshot focuses on a particular set of object instances and attributes, and the links between the instances

Object

Link

Attribute Values

Object Name

4 - 20

Comments

A correlated set of object diagrams provides insight into how an arbitrary view of a system is expected to evolve over time.

Object diagrams are more concrete than class diagrams, and are often used to provide examples, or act as test cases for the class diagrams.

Only those aspects of a model that are of current interest need to be shown on an object diagram.

In addition to class instances, you can also represent node instances, device instances, artifact instances, component instances, use case instances, actor instances, and so on.

4 - 21

Composite Structure DiagramA composite structure diagram reflects the internal collaboration of classes, interfaces, or components to describe a functionality.

It is used to express run-time architectures, usage patterns, and relationships that might not be reflected by static diagrams.

4 - 22

Comments

Composite Structure diagrams are similar to class diagrams, except that they model a specific usage of the structure. Class diagrams model a static view of class structures, including their attributes and behaviors.

When visualizing the system architecture, each of the internal parts may be a structured class that itself contains parts.

The internals of the Course Registration System are composed of three parts: StudentManagementSystem, BillingSystem, and CourseCatalogSystem.

A later slide will examine the internal structure of the StudentManagementSystem.

4 - 23

Complete the following tasks:Review Composite Structure Diagram Basics

Create a New Composite Structure Diagram

Challenge Yourself

To begin the lab:



Expand DEV396 Labs, then select Lab 06: Create Composite Structure Diagrams


Lab 06: Create Composite Structure Diagrams

4 - 24

A Component

A modular part of a system that hides its implementation behind a set of external interfaces.

Part of a logical or physical system

It conforms to, and provides the physical realization of, a set of interfaces.

It specifies the physical dependency to interfaces it requires.

4 - 25

Complete the following tasks:Review Component Diagram Basics

Create a New Component Diagram

Challenge Yourself

To begin the lab:



Expand DEV396 Labs, then select Lab 07: Create Component Diagrams


Lab 07: Create Component Diagrams

4 - 27

Deployment DiagramsDeployment is assigning, or mapping, software artifacts to physical nodes during execution.

Artifacts are the entities that are deployed onto physical nodes

Processes are assigned to computers

Artifacts model physical entities.Files, executables, database tables, web pages, and so on

Nodes model computational resources.Computers, storage units

4 - 28

Comments

A manifestation is the physical implementation of a model element as an artifact: a relationship between the model element and the artifact that implements it .

Model elements are typically implemented as a set of artifacts. Examples of Model elements are source files, executable files, and documentation files.

4 - 29

Complete the following tasks:Review Deployment Diagram Basics

Create a New Deployment Diagram

Challenge Yourself

To begin the lab:



Expand DEV396 Labs, then select Lab 08: Create Deployment Diagrams


Lab 08: Create Deployments Diagrams


Module 5 : Creating UML Diagrams of System Behavior

5 - 2

Module Objectives

After completing this module, you will be able to: Identify the behavioral UML diagrams available in Rational Software Architect

Identify UML notation and provide a basic explanation of UML semantics

Create use-case, activity, sequence, communication, and state machine diagrams in Rational Software Architect

5 - 3

Behavioral Diagrams in Rational Software Architect

Behavioral Diagrams

Structural Diagrams

ActivityDiagrams

SequenceDiagrams



ComponentDiagrams


ClassDiagrams

Use-CaseDiagrams

Model

ObjectDiagrams

DeploymentDiagrams

5 - 4

Comments

Visual models of a system require many different diagrams to represent different views of the system for different project stakeholders. The UML provides a rich notation for visualizing models, including the following key diagrams :

• Use-case diagrams to illustrate user interactions with the system


• Composite structure diagrams to show the internal structure of a class or component at runtime



• Activity diagrams to illustrate flows of events

• State machine diagrams to illustrate the series of states an object can have

• Communication diagrams to illustrate behavior in terms of how objects interact

• Sequence diagrams to illustrate behavior in terms of the sequence of interactions between objects

5 - 5

Use Case DiagramsUse case diagrams:

Model the behavior of a system, and help capture the requirements of the system

Describe the high-level functions and scope of a system

Identify the interactions between the system and its actors

Describe what the system does and how the actors use it, but not how the system operates internally

Illustrate and define the context and requirements of either an entire system, or the important parts of the system

Are typically developed in the early phases of a project, and are referred to throughout the development process

5 - 7

Use-Case Diagram Elements

ActorSomeone or something thatinteracts with the system

ActorSomeone or something thatinteracts with the system

Use CaseUnits of system behavior

Use CaseUnits of system behavior

5 - 8

Comments

The use-case model contains the following elements, which are displayed in a use-case diagram:

• Actors: Used to represent someone or something outside the system that interacts with the system.

• Use cases: Used to represent a unit of system behavior that comprises several possible sequences of actions.

• Relationships

• Include: Used when the use case modeler sees a piece of behavior that can be reused by more than one use case.

• Extend: Used when the use case modeler identifies an optional piece of behavior and places it in a separate use case.

• Generalization: Used when a generalization/ specialization relationship exists.

5 - 9

Lab 9: Create Use-Case Diagrams

Given:Create Use-Case Diagrams cheat sheet

Complete the following tasks:Review the basics of use-case diagrams

Create a new use-case diagram

Re-create an example use-case diagram from an image



Expand DEV396 Labs, then select Lab 9: Create Use-Case Diagrams


5 - 11

Activity

Activity is the specification of behavior expressed as a flow of execution through the sequencing of subordinate units.

An activity is generally modeled as one or more activity diagrams

5 - 12

Comments

Activity modeling emphasizes the sequence and conditions for coordinating lower-level behaviors, rather than which classifiers own those behaviors (that is what sequence diagrams are for). These are commonly called control flow and object flow models.

The actions coordinated by activity models can be initiated because other actions finish executing, because objects and data become available, or because events occur external to the flow.

5 - 13

Activity Diagrams

5 - 14

Comments

Activity diagrams are particularly useful in describing workflow, and a use case’s flow of events. They are similar to the old fashioned flow chart, but are utilized at a much higher level of abstraction than flow charting source code.

Activity diagrams can model control as well as data flow. Partitions (the parallel lines) provide a mechanism to describe high-level responsibilities and concurrency.

5 - 15

Action

An action is a fundamental unit of executable functionalityIt represents some transformation or processing in the modeled system

An action is a UML Element that you put INTO activity diagramsAn action represents behavior that you do NOT want to model in more detail – it is fundamental or atomic

5 - 16

A Call Behavior Action

A call behavior action represents a linked call to a separate activity (and its corresponding activity diagrams)

Drag an activity onto an activity diagram to create a call behavior actionDouble-click a call behavior action to open the linked activity’s diagram

5 - 17

A Call Operation ActionA call operation action is an action that transmits an operation call request

It is an action that is linked to a specific method or operation in a specific class (interface, subsystem, and so on)

The official name of the action is the name of the operation

Drag an operation onto the diagram to create a call operation action

5 - 18

Accept Event and Send Signal Actions

Accept eventAn action waiting for an eventActions that may be used by themselves, or may be paired with send signal actions

Send signalAn action that creates a signal instance and transmits it to the target object, where it may cause an activity to execute

5 - 19

A Structured Activity Node

A structured activity node represents a structured portion of the activity that is not shared with any other structured node

It is a nested activity with a corresponding activity diagram

5 - 20

Partitions

5 - 21

Control Flow

Control flow:Is the set of lines connecting the activities and actions (activity nodes)Represents the flow of control from one node to anotherCan have guard conditions

Control Flow

5 - 23

Control Nodes

Control nodes coordinate the flow in an activity

Initial

Decision/Merge

Fork/Join

Activity End

Flow Final

5 - 24

Comments

Initial: The starting control node of the activity.

Decision: A decision node has one incoming flow and multiple outgoing flows, of which only one will be taken. Guard conditions should be made to insure that only one flow can be taken.

Merge: A control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows, but to accept one among several flows.

Fork: A control node that splits an incoming flow into multiple concurrent outgoing flows. Tokens arriving at a fork are duplicated across each outgoing flow.

Join: A join node is a control node that synchronizes multiple flows. If there is a token offered on all incoming flows, then a token is offered on the single outgoing flow.

Activity End: A node that stops all flow activity.

Flow Final: A node that terminates that flow.

5 - 25

Object Flow

Object flow models the data flow within an activityObject flow can only be attached to object nodesObject nodes and object flow provide the capabilities for explicit data flow modeling

5 - 26

Given:Create Activity Diagrams cheat sheet

Complete the following tasks:Review the basics of activity diagrams

Create a new activity diagram

Re-create an example activity diagram from an image



Expand DEV396 Labs, then select Lab 10: Create Activity Diagrams


Lab 10: Create Activity Diagrams

5 - 27

Interaction Diagrams (1 of 2)

Interaction diagrams show how objects interact, and the order of their interactionsThere are several types of interaction diagrams that emphasize object interactions, including the messages that may be dispatched among them:

Sequence diagram Communication diagramInteraction overview diagram

5 - 28

Interaction Diagrams (2 of 2)

Sequence diagramTime-oriented view of

interactions

Communication diagramStructural view of messaging

roles or parts

Interaction overview diagram

High-level view of interaction sets combined with logic

comm

sd

intover

5 - 29

Sequence Diagrams Versus Communication Diagrams

Show relationships in addition to interactionsBetter for visualizing patterns of collaborationBetter for visualizing all of the effects on a given role or partEasier to use for brainstorming sessions

Show the explicit sequence of messagesBetter for visualizing overall flowBetter for real-time specificationsBetter for complex scenarios

Communication Diagrams

Sequence Diagrams

5 - 30

The Anatomy of Sequence Diagrams

Message ReflexiveMessage

Hierarchical MessageNumbering

Lifeline Role

EventOccurrence

Execution Occurrence

5 - 31

Example: Sequence Diagram

5 - 32

Comments

By creating an interaction use, you can encapsulate complex behaviors to their own sequence diagrams.

Double clicking the interaction use will allow you to navigate to the encapsulated sequence diagram. This technique gives you the ability to develop complex sequence diagrams in a simplified manner.

5 - 33

Combined Fragments

Combined fragments represent a grouping of behavior shown as a nested region within a sequence diagram:

Define conditional structures in interactionsDescribe several traces in a compact and concise manner

InteractionOperand

GuardExpression

CombinedFragment

CombinedFragment

InteractionOperator

5 - 34

An Interaction Operator

An interaction operator identifies the type of combined fragment

The loop operand indicates that the Fragment is executed repeatedlyThe alternative

operand identifies a set of behaviors from which only one will execute on any one pass through the interaction

5 - 35

The Guard Expression

The guard expression is a Boolean conditional expression that guards an interaction operand:

Appears at the start of the operandIs used to determine

if, or how long, the operand will be executedIts absence equates

to a true condition

5 - 36

An Interaction Operand

Each combined fragment is made up of one or more sections

The number of operands depends on the type of combined fragment

For example, a loop has one operand (the loop body), and an alternative has one or more operands (the branches of the conditional)

Each operand covers the lifelines (or a subset of them) contained by the combined fragment

5 - 37

Communication Diagram

5 - 38

Given:Create Sequence Diagrams cheat sheet

Complete the following tasks:Review the basic editor, tools, and elements in a sequence diagram.

Create a new sequence diagram

Re-create an example sequence diagram.



Expand DEV396 Labs, then select Lab 11: Create Sequence Diagrams


Lab 11: Create Sequence Diagrams

5 - 39

Given:Create Communication Diagrams cheat sheet

Complete the following tasks:Review the basics of communication diagrams

Create a new communication diagram

Re-create an example communication diagram from an image



Expand DEV396 Labs, then select Lab 12: Create Communication Diagrams


Lab 12: Create Communication Diagrams

5 - 40

A State Machine Diagram

State: “a recognizable situation that exists over an interval of time” ~ Hassan GomaaState transitions: Possible paths the system may take from one state to anotherTriggering events: Instantaneous events that stimulate state transitionsActions: Work the system does in response to events

5 - 41

States

States can have entry, exit, and do activities that are performed while in the state

Executed when the state is entered, after any activity attached to the incoming transition, and before any internal do activity

Described by an expression and executed after the entry activity is completed, but before any exit activity

Executed when the state is exited, after the completion of the do activity and before any activity attached to the outgoing transition

5 - 42

Transitions

A transition is the path taken during a change of state from one state to the next in response to a triggering eventGuard condition: Optional condition to be evaluated; if false, the transition is not taken

5 - 43

Regions

Regions provide the ability to show concurrent orthogonal states

Think of orthogonal states as separate state machines that operate in parallel

Parallelism is achieved by the introduction of regions

5 - 44

Composite States

Composite states are states that contain other states and regions

5 - 45

Orthogonal States

Orthogonal statesAre composite states with two or more regions within the state.

5 - 46

Submachine State

A submachine state is a decomposition mechanism that allows factoring of common behaviors and their reuse

Similar in concept to the call behavior action in activity diagrams

Semantically equivalent to a composite state

5 - 47

PseudostatesInitial State: Marks the start of the machineChoice Point: Supports dynamic branchesJunction Point: Supports static branchesDeep History: Return to the most recent substateShallow History: Return to the most recent stateJoin, Fork: Similar to activity diagramEntry, Exit Point: Used to designate a default entry or exit into a composite state or state machineTerminate: Marks the end of the state machine’s execution

Combine and direct transitions

5 - 48

Choice PointsChoice points realize a dynamic conditional branch

Actions can change subsequent guard condition evaluations

Only the initial guard conditions are evaluated before transitions are fired

When the Choice Point is reached, the outgoing segments are evaluated

Clarifies state machine modeling

Visualizes implementation decisions at the modeling level

5 - 49

Junctions

Junctions realize a static conditional branch

Actions will not change subsequent guard condition evaluations

All guard conditions are evaluated before transitions are fired

If all guard conditions return false, then remain in the source state

Simplify state machine modeling

Chain together multiple transition segments

5 - 50

History

Deep HistoryRepresents the most recent active configuration of the composite state that directly contains this pseudostateA composite state can have at most one Deep History vertex

Shallow History Represents the most recent active substate of its containing state (but not the substates of that substate).A composite state can have at most one Shallow History vertex.

5 - 51

Given:Create State Machine Diagrams cheat sheet

Complete the following tasks:Review the basics of state machine diagrams

Create a new state machine diagram

Recreate an example state machine diagram from an image



Expand DEV396 Labs, then select Lab 13: Create State Machine Diagrams


Lab 13: Create State Machine Diagrams


Module 6 : Team Development

6 - 2

Module Objectives


Describe team development best practices with Rational Software Architect.

Compare and merge diagrams in Rational Software Architect.

Combine diagrams in Rational Software Architect.

Publish and share diagrams with other team members.

6 - 3

Software Architect and Team Development

Architect

Create and publish models

Transform design model into code

Verify architecture and code with structural code review

Developer

Consult published models and artifacts

Elaborate the code

Verify code with code reviewRepository

6 - 4

Comments

The following Rational Software Architect features facilitate collaboration between architects and developers :

TransformationRational Software Architect’s model transformation features allow architects to create basic code structures from high-level UML models, which can be used as a starting point for developers.

Code ReviewThe code review feature is used to analyze code against the project’s architectural guidelines. Code review includes :

• Structural anti-pattern detection to assist in Java refactoring

• Structural rules (including user-defined rules) to enforce architectural control of Java code

Web PublisherWhile creating detailed implementation code, the developer can refer to Web-published models and UML injected Javadocs, which Rational Software Architect can generate automatically.

6 - 5

SCM Best Practices: Model Partitioning

Partition the model to avoid unnecessary merges

Factors to consider when deciding how to partition a model:

Stabilize abstraction levels

Minimize dependencies between models

Establish ownership policies

Avoid broken references

6 - 6

Comments

While the Compare and Merge features in Rational Software Architect are advanced and easy to use, model merge scenarios can become complex and prone to user error if the models involved are needlessly complicated and disorganized. To optimize your models for configuration management and team development, you should observe the following principles :

• Stabilize abstraction levels: Do not partition the model until the top-level subsystems are clearly defined. Once the subsystems are mature and stable, you can separate them to enable parallel development and to improve the speed with which the model opens. When an individual subsystem’s contents stabilize, you can then separate the subsystem from the model.

• Minimize dependencies between models: By minimizing dependencies between models, you can reduce the likelihood that a change in one model will affect another. If you allow dependencies between models, widespread conflicts can occur that must be resolved with out-of-context model merges (which are very challenging).

• Establish ownership policies: Assigning different model files to different team members can help avoid conflicts when you deliver the model to a shared work area. It can also help speed integration. You should establish the size and scope of each model so that a single person can work on it.

• Avoid broken references: Whenever you move a model partition outside of your configuration management system, you break that model file's references. You have to repair these broken references whenever you reintegrate the model back into the CM system. It can be time-consuming and error-prone to resolve a large number of references in a complicated model.

6 - 7

To partition a model, you can:Create fragments

An element that has been converted into a fragment has this icon:

Create new models from packagesA package that has been made into a model has this icon:

Absorb fragments back into the model

Copy packages from partitions back into the main model

Model Partitioning

Creating a model from a package automatically leaves a shortcut reference to the new model where the package used to be.

Creating a model from a package automatically leaves a shortcut reference to the new model where the package used to be.

Creating a fragment from a model element adds an adornment to the element and creates a separate file for that element.

Creating a fragment from a model element adds an adornment to the element and creates a separate file for that element.

6 - 8

Comments

You can refactor an existing model file into several, smaller model files in Rational Software Architect.

To separate a package from a model into a new model file, right-click the package and then click Create Model From Package.

To reassemble the model after it has been partitioned, you must copy and paste the packages back into the main model.

To create a fragment, select a model element, right-click and select Create Fragment.

To absorb the fragment back into the model, right-click the fragment and select Absorb Fragment.

6 - 9

Partition and Fragment Files

After you have created a partition and a fragment, Rational Software Architect will create new files to represent these elements. You can view all of the files in the Navigator view.

Design Model.emx is the original model that you started with.

Design Model.emx is the original model that you started with.

you have two fragments that have been created in relationship to this model. So you have two .efx files within your project.

you have two fragments that have been created in relationship to this model. So you have two .efx files within your project.

In addition, you specified that you wanted to convert the presentation package into its own model. So there is another .emx file.

In addition, you specified that you wanted to convert the presentation package into its own model. So there is another .emx file.

6 - 10

FragmentsFragments model elements into separate files

Model Element Fragments:All model elements – down to the class level

Activity Diagrams

Composite Structure Diagrams

State Machine Diagrams

Communication Diagrams

Diagrams that cannot be made into Fragments:

Class Diagram

Object Diagram

Freeform Diagram

Deployment Diagram

Component Diagram

When viewing details of a model in the UML model editor, you can see fragments associated with it by clicking the Fragments tab at the bottom of the editor.

When viewing details of a model in the UML model editor, you can see fragments associated with it by clicking the Fragments tab at the bottom of the editor.

6 - 11

Compare and Merge Models

Rational Software Architect allows you to merge model and diagram files using the compare and merge utility.

Compare models to identify changes between model versions.

Merge models when:Parallel development occurs

Alternative approaches are explored

Circumstances dictate

Avoid situations that require frequent merging.

6 - 12

Comments

You can compare two or three models with a common ancestor to find the differences among them outside a source-controlled environment, or within a team environment, using a configuration management system such as ClearCase. A new feature also allows you to compare models without common ancestry.

The Compare feature can be used to compare versions of models just to see what has changed between versions as part of everyday modeling work, particularly in collaborative settings. Compare and merge becomes essential in more complicated team development settings, such as parallel development.

Compare and merge scenarios can often become very complicated and difficult to resolve if they are not carefully controlled. When working with large and complicated models, compare and merge should be avoided except when absolutely necessary.

6 - 13

Merging Models

Begin with a base contributor, the common ancestor of the models you wish to merge.

Have up to three contributors (modified versions of the base model) in a merge session.

1

12

3

Contributor 1Contributor 1

BaseContributor

BaseContributor

Contributor 2Contributor 21

Merge

6 - 14

Comments

The slide shows the simplest and most common compare and merge scenario :

• You and a colleague work on copies (Contributor 1 and Contributor 2) of a model file (Base Contributor) that is under source control.

• You both make changes to your copies.

• Your colleague checks in changes (creating Base Contributor version 2).

• You try to check in changes.

• The SCM system detects that the latest version in the repository (BC version 2) is not the version you checked out and modified (BC version 1).

• The SCM system detects that your version cannot replace the version in the repository, or else you lose your colleague’s changes.

• The SCM system attempts to merge your changes into the latest version (BC version 3) in the repository.

6 - 15

Compare Editor

Structural Differences•Accept or Reject changesStructural Differences•Accept or Reject changes

Merged ModelMerged Model

Left Contributor Left Contributor Right ContributorRight Contributor

6 - 16

Comments

Given multiple versions of a model that were modified in parallel, you can merge the models by starting a merge session and using the Compare editor. Once you resolve all conflicts among the contributors, you can save the final merged model as a new version. When you compare two versions of a model, their differences are displayed in the Difference editor.

When working with a version control system, such as ClearCase, a merge session may start automatically when you check in a file under version control. After merging models, saving the merged model, and closing the session, the process that initiated the check-in process continues.

Automatic mergesDuring an automatic merge, all differences and trivial conflicts are merged automatically. If the software automatically makes a resolution, a resolution icon is displayed beside the resolved difference in the Structural Differences view. The software also generates a merged model for these resolutions.If the merged model contains conflicts, a conflict icon is displayed beside each conflicting element in the Structural Differences view.

Manual mergesDuring a manual merge, you resolve the differences or conflicts. You can right-click a difference or conflict and then Accept or Reject it. You can also accept or reject groups of differences or conflicts.You can start a manual merge session in the following ways:

• Merge models in a ClearCase version or history interface

• Compare models in an Eclipse resource view that has one or more modifiable resources

6 - 17

Compare and Merge FeaturesDiagram notational merge

Merge notational changes individually, just as you can with diagrams in a model file

Revert session

Allows you to restart a merge without exiting the merge application

Package composite deltas

Allows you to accept and reject changes at any package level in the hierarchy

Validating models before ClearCase check-in

Validate each model merge before committing the update to ClearCase

Field-level merge

Resolve conflicting changes by merging multi-line text fields in which scripts or snippets of java are embedded

Full context merge

Allows you to merge the entire model instead of merging individual artifacts

Automated profile upgrade

Automatically upgrades to the latest profile version

6 - 18

Comments

While you are learning how to handle merges, it is possible to get far into a merge only to realize that the approach is incorrect and you need to start over. The Revert Session button makes this easy. It is particularly helpful when you are in the middle of a ClearCase operation, because ClearCase merges all artifacts in sequence, and interrupting and restarting the flow can be tedious.

Validating models before ClearCase check-in is useful during a long ClearCase operation, such as when you are delivering many changed artifacts. It can be extremely helpful because you don’t need to remember which models need validation. Rather you can perform the validation immediately after the merge while all decisions are fresh in your mind.

Full context merge allows you to synchronize the workspace to the repository in a logical model mode. It provides a stronger merge experience, as each delta and conflict is generated with knowledge of the full context of the models. This eliminates a common source of corruption: the resolution of related conflicts to opposite contributors.

The Automated profile upgrade feature prevents the merge from aborting when a contributor is found to be using a newer version of a profile.

6 - 19

Lab14: Compare and Merge a ModelIn this lab, you will learn how to compare and merge a model using the Model Compare editor.


Compare models

Merge models

To begin the lab:



Expand DEV396 Labs, then select 14 Compare and Merge Models.


6 - 20

Combine ModelsPending Changes•Mark changes from source model to be applied to target model.

Pending Changes•Mark changes from source model to be applied to target model.

Source ModelSource Model Target ModelTarget Model

You can combine models that are not related by a common ancestry, such as independently created models.

You (as a modeler) might use this feature if you want to assemble a number of models, ones that were created informally at the beginning of your project, into a formal set of models that can be managed with version control.

Change DescriptionChange Description

6 - 21

Lab15: Combine Models

In this lab, you will learn how to combine dissimilar models.


Combine models

To begin the lab:



Expand DEV396 Labs, then select 15 Combine Models.


6 - 23

Model Publishing

Publish the entire model to HTMLPublish reports to PDF

Model diagram report

Sample UML metric report

6 - 24

Comments

When you publish a model as a Web site, you indicate the scope of data to include, how much about that data to include, and where you want to save the published model.

Each published model is a separate, wholly contained entity with its own root page. When you publish, theroot page has a link to each included model. It is the current version of the model that is published.

Reports can also be generated using IBM® Rational® SoDA®. SoDA provides cross-tool reporting. It does the work of connecting to a Rational Software Architect model and retrieving data relevant for its reports. In SoDA, you can customize the templates to get the layouts and data that you want.

6 - 25

Lab16: Publish a Model and Generate a Model Report

In this lab, you will learn how to publish a model and generate a model report.


Publish a model

Generate a model report

To begin the lab:



Expand DEV396 Labs, then select 16 Publish and Generate Reports.



Module 7 : Applying Patterns and Transformations

7 - 3

Module Objectives

Apply reusable assets in the development process.

Apply a pre-built design pattern in Rational Software Architect.Perform model transformations

Forward transformations

Reverse transformations

7 - 4

Comments

This module introduces patterns and asset-based development in Rational Software Architect, methods for reusing effective development artifacts and applying best practices in a project.

Patterns offer a way to capture, reuse, and share solutions to common problems and a common language for describing problems and solutions. Patterns implemented in a development tool like Rational Software Architect help automate access to, and the application of, patterns. Design patterns and transformations in Rational Software Architect help automate routine modeling and coding tasks.

7 - 5

What is a Pattern ?

A solution to a recurring problem in a given context.Patterns abstract a way of solving a design problem from the details of any particular technology

A pattern:Provides a solution to a specific problemRequires a strategy for applying the pattern in its context.Comes with consequences (advantages and disadvantages) of applying the pattern.

7 - 7

Patterns in Rational Software ArchitectThree features for automating model development with patterns:

Design Patterns: Add details to the model. Provide model markup and structures that can be transformed into code.

Observer pattern

Session Facade pattern

Transformations: Translate elements from one model into elements in a different model1. Model-to-model 2. Model-to-code3. Code-to-model

Java Emitter Templates (JET)transformations: a type of transformation that provides customizable, text-based transformations and code templates Transformations

Pattern

1

2

3

7 - 8

Comments

In Rational Software Architect, design patterns and transformations are two forms of pattern implementations. Design patterns are sets of model elements that are parameterized to be fitted into any existing model, to speed model development and mark up the model with UML stereotypes from a profile recognized by a model transformation. Transformations can be used to translate model elements from one model to another automatically, to speed the transition of elements from, for example, analysis to design or from design to implementation.

Design PatternsDesign patterns allow you to make use of existing solutions developed in the same type of model that you are working on. So, for example, the Observer GoF pattern in Rational Software Architect contains design-level UML classes that can be applied in a design-level UML class model. Patterns have parameters so that you can customize them for a specific context, but patterns do not automatically translate themselves to work in different model types. You cannot, for example, apply a design pattern and get a code-level idiom in Java code without using transformations.

TransformationsTransformations take elements from one model and translate them into elements of a different model. For example, you can apply a transformation to move from a platform-independent model to a platform-specific model as you add in details about the platform and get closer to the implementation. When adding levels of refinement, you can transform from a platform-specific model to another, adding more details without changing the model type. Transformations are often applied to whole models, but they can be applied to selections from models as well.

7 - 9

The Pattern Explorer view

Design Pattern

Transformation

JET Transformation

Right-click to apply, copy, move, or configure the pattern, or to view documentation.

Icons in the Pattern Explorer view

7 - 10

Comments

The Pattern Explorer view, associated with the Modeling Perspective, is split into two panes:

Pattern tree: Presents a hierarchical list of patterns, organized into pattern groups.

• By right-clicking items in the pattern tree, you can copy and move patterns and groups, and delete and rename groups.

• By right-clicking a pattern, you can choose to apply the pattern using the Apply Pattern wizard, or open the pattern’s full documentation in Help.

• By dragging a pattern onto the drawing surface, you can create a pattern instance that can have its parameters bound by drag-and-drop actions.

Info pane: The information pane has two tabs that provide information about the pattern selected in the pattern tree.

• The Overview presents a participants class diagram, showing what objects participate in the pattern.

• The Short Description provides a brief summary of the problem and the solution the pattern provides. If you have a pattern participant selected, the Short Description describes the participant.

7 - 11

Design Patterns in Rational Software ArchitectA design pattern in Rational Software Architect adds details to a model automatically. Use design patterns to add:

Model elements and relationshipsClasses, packages, and so on

Details to model elementsAttributes, operations

Markup to the modelStereotypes from a UML profile recognized by transformations

A design pattern:Has parameters that are used to bind the pattern to the modelCan be reapplied to or unbound fromthe modelUsually affect small areas of the model when applied

7 - 12

Comments

Like all pattern implementations, a design pattern in Rational Software Architect provides a software solution to a recurring problem within a given context. The limitations of a pattern are determined by the pattern design, and the intent of the pattern author. The scope of a design pattern in Rational Software Architect is most often a singular problem, affecting a small part of the model when applied, such as a specific use case being modeled.

A design pattern can :

• Add elements and relationships to a model, such as groups of classes, actors and use cases, packages, and so on.

• Add details to model elements, such as attributes and operations to a class.

• Add markup to the model. In other words, add stereotypes to model elements from a UML profile to create elements such as analysis classes, subsystems, and platform- and technology-specific elements.

7 - 13

Design Pattern Notation

Parameters

Pattern InstanceA UML Collaboration

Binding Indicator

Parameter Type

Multiplicity Bound Arguments

7 - 14

Comments

Pattern instances in Rational Software Architect are represented with UML collaborations that are stereotyped «pattern instance».

A pattern instance includes the following features :

• Parameters: Each parameter in the pattern instance takes an argument. When bound, the icon changes to a blue box containing a double arrow.

• Parameter Multiplicity: The parameter’s multiplicity is shown in brackets after the parameter name.

• Parameter Type: After the multiplicity, an icon or text shows the parameter type (for example, class, interface, or operation).

• Binding Indicator: An icon or text that shows whether the parameter has an argument bound to it. An empty blue box indicates that no arguments are bound to the parameter. A binding icon shows that arguments are bound to the parameter.

• Arguments: One (or more, if the pattern allows it) arguments may be bound to the parameter.

7 - 15

Applying a Design PatternCreate a pattern instance by dragging a pattern from the Pattern Explorer view to an open diagram, or to a model in the Project Explorer view.

1

Drag an existing class from the diagram or Project Explorer view to a pattern parameter to make it an argument of the pattern, or…

2Use the action bar to create an argument value for a parameter.3

7 - 16

Comments

Applying a pattern is a two-step process: you first add an instance of a pattern to the model, and then select (or “bind”) argument values for the pattern—either existing elements of the model or new elements that you create while applying the pattern.

There are two ways to apply patterns in Rational Software Architect :

• Apply the pattern using the Apply Pattern wizard. Select a model as the location for the pattern instance and then select or create elements to use as argument values. You can continue to add argument values to the pattern instance after using the wizard.

• Apply the pattern interactively, using the Pattern Explorer view and the diagram editor. Drag the pattern from the Pattern Explorer and drop it onto an open diagram. If you click or hover the mouse over a parameter in the pattern instance, the action bar will appear, allowing you either to select an existing element in the model or to create a new one as the argument value. You can also drag and drop an existing model element, either from the diagram or from the Model Explorer view, onto a pattern instance’s parameter to bind that element to the parameter.

To “unapply” a pattern, right-click the pattern instance and then click Patterns > Unapply. The pattern instance is deleted and all bindings to model elements are deleted.

7 - 17

Gang of Four (GoF) Design Patterns

Rational Software Architect has the 23 GoF design patterns built in:

Can be used as the basis for custom patterns

These patterns support widely recognized best practices

Help seed the code with transformation extensions

ExampleObserver is a GoF behavioral design pattern:

One-to-many dependency between objects When one object changes state, observers are notified and updated automatically

7 - 18

Comments

The 23 Gang of Four design patterns are included with Rational Software Architect’s patterns library. The Gang of Four patterns are grouped into Behavioral, Creational, and Structural varieties. For example, the Behavioral set of patterns includes the Observer pattern. Observer is used in cases when a ConcreteSubject object needs to inform other objects that have registered an interest that some change inside it has occurred. When these objects have been notified, they interrogate the ConcreteSubject object to see if the change requires them to take action (see Gamma et al., pp. 293–303).

7 - 19

Complete the following tasks:Examine the Observer design patternCreate the UML modeling projectSelect a PatternApply a PatternView Pattern Relationships

To begin the lab:In Rational Software Architect, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog.


Expand DEV396 Labs, then select Lab 17: Apply Patterns.

Follow the instructions indicated in the cheat sheet.

Lab 17: Apply Patterns

7 - 20

TransformationsTransformations create elements in a target model (domain) based on elements from a source model

Often, the source domain is more abstract than the target domain

Examples:Based on a use-case model, create an analysis model that realizes the use cases following a modeling standardBased on the analysis model, create a design model that incorporates elements of the company’s security and persistence frameworks, and follows a modeling standardStarting with a UML model, apply a built-in transformation to create code elementsTake existing code and apply a transformation to abstract out the design elements.

Transformations

7 - 21

Transformations in Rational Software ArchitectThe following transformations are built in to Rational Software Architect:

UML to UMLUML to LDM

UML to codeUML to Java V1.4UML to Java V5.0UML to C++UML to EJBUML to WSDLUML to XSD

Code to UMLC++ to UMLJava to UML

UML to SQL / DB / RelationalTransformations can be custom built using the Plug-in Development Environment.

7 - 22

Rational Data Architect

Enterprise Data Modeling and Integration Design tool

Eclipse-based user experience

Visualize

entity relationship diagram, topology

diagram

Standardize

naming standards, normalization,

enterprise rules

Federate

federated schema, nicknames, views

based on nicknames

XML

XML schema editorXML mapping

XML shredding

Model

logical and physical data model, entity

relationship diagram, storage diagram,

domain model

Relate

model to model mappings, mapping

discovery, ER to XML mapping

Synchronize

model to model comparison and sync,

model to database comparison and sync

Code

SQL editor, stored procedures wizard, debugger for DB2

Teamversioning

governance

Import/Exportmodelsglossary

Storemodels

SQL and XML files

Integraterequirements

transformations

7 - 23

Create a Database Model

Initiate information design with a transformation from system architecture models orReverse engineer your current databases to create a data model orImport your existing data model from other tools orCreate the model based on a model template

7 - 24

Integration with Rational Software ModelerRational Software Modeler and Rational Data Architect installation in the same shell instance

Same user experience as in Rational Data ArchitectModeling perspective includes functionality for data modeling and UML data modelingData perspective includes the same physical metamodelsand features as in Rational Data Architect

7 - 25

Model Transformation

Transformations between application modeling in UML and data modeling in Rational Data Architect

Top-down application design (UML-to-LDM) generate logical data model from analysis modelGenerate data access

model or service model from logical data model (LDM-to-UML)

7 - 27

Reverse Transformations

Java and C++ transformations can be reversedEnable a reverse transformation in the transformation configurationAllows you to synchronize changes between UML models and C++ and Java code

If necessary, compare and merge session starts when transformation is run

7 - 28

Comments

In the transformation configuration of a C++ or Java transformation, you can enable a reverse transformation (so that you can always transform both model to code and code to model). The reverse transformation transforms Java source objects into UML objects and stores these objects in the UML model that you specify. In the process, certain platform-specific details are optionally removed.

Forward and reverse transformation can be used to maintain both a detailed design model in UML of the solution and its detailed code, so that you can make changes either at the level of the code itself (either using the code editor, or visually, using UML visualization), or in the model.

7 - 29

Reconciliation: Merge the Transformed Model

The combine dissimilar models feature is used when you apply a transformation to update a conceptual model from Java or C++ code.



Source ModelSource Model Target ModelTarget Model

Change DescriptionChange Description

7 - 30

Comments

The combine dissimilar models feature is used when you apply a transformation to update a conceptual model from Java or C++ code. This step in the reverse transformation allows you to select which features from the source to keep in the target. It is also used to reconcile changes, when changes in the model and the code need to be merged.

7 - 31

UML Visual Development

C++ and Java code can be visualized with class and sequence diagrams

Changes to the code update the diagramChanges to the diagram update the codeHarvest classes into UML models

7 - 32

Comments

Rational Software Architect includes visual editing (or UML visualization) capabilities for Java and C++ code, including class and sequence diagrams. With these tools, you can develop projects using your existing workflow and leverage UML to:

• Visualize code

• Document code

• Construct and maintain code visually

You can create visualizations that abstract many of the code details to simplify the understanding of code structure and behavior. Content in the diagrams is configurable so that you can define your own context. Visual editing automates the expansion of the diagrams and serves to facilitate the discovery of an application.

You can export or copy and paste diagram images into documents, such as Microsoft Word. To obtain detailed reports, you can publish diagrams and code into a Portable Document Format (PDF) report that can be archived or distributed for review.

Visual editing can make coding more efficient. It includes support for creating classes, attributes (or fields), methods, and relationships in the diagram (excluding topic diagrams) automatically.

7 - 33

Lab 18: Run a UML to Java Transformation

Complete the following tasks:Task 1: Create the UML modeling projectTask 2: Create UML ClassesTask 3: Transform UML Classes to Java ClassesTask 4: Perform reverse transformation

To begin the lab:



Expand DEV396 Labs, then select Lab 19: Run a UML to Java Transformation.


UML to Database Generation with RSA and RDA

7 - 35

Rational Software Architect

Rational Software Architect (RSA) is an application modeling tool that enables an organization to model, analyze, design, and generate applications. It leverages model-driven development with UML for creating well-architected applications and services. RSA :

• Extends the Eclipse open and extensible software development environment.

• Exploits the latest in modeling language technology, enabling flexible modeling across a variety of different domains including UML 2, UML-like notation for Java and more.

• Enables flexible model management for parallel development and architectural re-factoring; for example, you can split, combine, compare and merge models and model fragments.

• Eases the transition between the architecture and code with model-to-model and model-to-code transformations, including reverse transformations.

• Eases the design-to-code experience for Java™/J2EE™, Web Services, SOA and C/C++ applications.

• Includes all of the features of IBM Rational Application Developer for an integrated design and development experience.

Classes in RSA can be anything that is created, assembled, inspected, tested, modified, or worked upon in applications.

7 - 36

Figure 1. Sample Class Model in RSA Invoice project

Figure 1 below shows a few sample classes, and their associations, – Invoice, InvoiceItem, ProductInvoiceand ServiceInvoice from a sample RSA project called Invoice. Note that there are three different types of associations shown: composition (invoice – item), aggregation (main – associate) and simple association (product - service). These associations are discussed later in this article.

7 - 37

Rational Data Architect

Rational Data Architect (RDA) is an enterprise data modeling and integration design tool. It simplifies data modeling and integration design, enabling architects to discover, model, visualize and relate diverse and distributed data assets. Using RDA one can:

• Create logical and physical data models.

• Compare and synchronize the structures and elements of two data models.

• Analyze data models for correctness and conformance to enterprise standards.

• Discover, explore and visualize the structure of data sources.

• Use mapping to discover potential relationships and identify relationships between disparate data sources.

Figure 2 below shows a sample LDM from the sample RDA project called Invoice. Note that there are three types of relationships: identifying (item – invoice), non-identifying (associate - main) and many-to-many (service - product). Note also that key inheritance occurs for generalizations and key migration occurs for identifying and non-identifying relationships. This is discussed later in this article.

7 - 38

Figure 2. Sample Logical Data Model in RDA “Invoice” project.

Logical Data Models were frequently overlooked in the software development life cycle, but have become increasingly important for many reasons. LDM provides a view of the data entities in a business or an enterprise without exposing implementation details; it separates data semantics from implementation and is especially useful when dealing with today’s increasingly complex and heterogeneous IT environments. Other logical or physical models, such as service models, message models, class models and data warehousing models, can all be traced to a common LDM. With state-of-art, model-driven development tooling such as Rational Data Architect and Rational Software Architect, the user can even generate downstream models and physical implementations based on LDM. It is not an exaggeration to say LDM is the information hub of an organization. LDM allows an enterprise view of data, which in turn helps to reduce data redundancy, improve data quality, and speed up integration.

7 - 39

Integration Scenarios

There are three primary scenarios for the integration of application modeling and data modeling: top-down, bottom-up and meet-in-the-middle. The following sections describe each of the scenarios in more detail. The assumption is that two main IT roles are involved – The Application Modeler performs application modeling, and the Data Modeler carries out data modeling.

Top-down: Application Modeling to Data Modeling

In the top-down scenario, class modeling elements (classes, properties and associations) in RSA are transformed into LDM modeling elements (entities, attributes and relationships) for use in RDA. The steps in this scenario are :

1. The Application Modeler models applications in RSA. Business or application data is captured as class models.

2. The Application Modeler transforms part, or the whole, of a class model into a LDM using the UML-to-LDM transformation.

3. The Data Modeler accesses and imports the LDM in RDA 4. The Data Modeler transforms the LDM into a Physical Data Model (PDM) and further generates

database schema using RDA.

7 - 40

Figure 3. Top-down Integration Scenario: Application Modeling to Data Modeling.

The following diagram shows the interaction between the Application Modeler and the Data Modeler in the top-down scenario:

7 - 41

We recommend organizations consider using the top-down scenario when a combination of the following conditions is true:

• Application modeling is driving the project initiative.

• Applications cut across business units or silos.

• Applications are object centric and have limited requirements for data management other than persistence.

• LDM is not available.

• Physical database schema does not exist.

However, people sometimes adopt the top-down scenario for the wrong reasons. The following (in quotes) are some poor reasons for deciding to adopt the top-down scenario; they are followed with an counterargument against adopting the top-down scenario:

• “We have never done LDM before.” There is always a first time. If your organization has cut corners on LDM in the past, the sooner LDM efforts start, the better off the organization will be in the long term.

• “We don’t have LDM skills.” A good data modeler is worthy of investment so you should hire someone or develop people internally with LDM skills.

• “We only need to persist data for use by this application.” Most enterprise applications will need to share persistent data with other enterprise applications. A LDM will reduce Total Cost of Ownership.

Finally, the cons of using the top-down approach need to be addressed:

• Data models may become tightly-coupled with particular applications.

• Class models may not be readily reusable in LDM due to de-normalization and object-centric modeling in application modeling.

7 - 42

Bottom-up: Data Modeling to Application Modeling

In the bottom-up scenario, LDM modeling elements (entities, attributes and relationships) are transformed into class modeling elements (classes, properties and associations) for use in RSA. From an enterprise perspective, in the long run, it is preferable to use the bottom-up than the top-down approach because of the limitations of the top-down approach and the many benefits coming with LDM, as mentioned in the previous sections. In addition, the bottom-up approach allows the separation of concerns – the Data Modeler concentrates on developing an enterprise-wide vocabulary and data models; the Application Modeler focuses on application modeling.

The steps in this scenario are:

1. The Data Modeler models data in a LDM in RDA. In those cases where there’s an existing database schema but no physical or logical model, the Data Modeler derives a PDM from the existing schema, and transforms the PDM into a LDM.

2. The Data Modeler transforms part, or the whole, of a LDM into a class model using the LDM-to-UML transformation.

3. The Application Modeler accesses and imports the class model in RSA.

7 - 43

Figure 4. Bottom-up Integration Scenario: Data Modeling to Application Modeling

The following diagram shows the interaction between the Application Modeler and the Data Modeler in a bottom-up scenario:

7 - 44

We recommend that organizations consider using the bottom-up scenario when a combination of the following conditions is true:

• A LDM on that domain is already available. • There are several existing data sources (relational databases or other). • The organization wants to de-couple data from applications and manage data from the enterprise-

level. • The organization wants to create reusable information across the enterprise. • Multiple initiatives are involved; for example, business application rewrite along with a requirement

to tie into a data warehouse. • Applications are complex and frequently in flux. • Applications are data-centric. • The project needs to consider, at least in part, existing data models. This can happen if you have

legacy applications, third-party applications, or standards-based interfaces to satisfy.

Finally, the bottom-up approach also comes with a price:

• Some semantics may be lost during the transformation from a LDM to a class model because LDMshold richer data semantics (as in, primary keys) than class models.

• Because LDMs tend to be more complete than class models, if LDMs are pushed into class models without appropriate communication, the details might overwhelm Application Modelers. If the Application Modeler doesn’t understand LDMs, they may end up re-inventing the wheel and define entities or attributes that are already in LDMs. Thus, proper education and communication between the Data Modeler and the Application Modeler is essential. Ideally Application Modelers should be educated on how to understand and leverage logical data models.

7 - 45

Meet-in-the-middle

The previous sections describe both the top-down and bottom-up scenarios, which primarily focus on new development. However, change is the only constant in software development. Application modeling and data modeling should rarely be a one-time shot. To avoid obsolescence, application modeling and data modeling need to be iterative and deliver business value quickly. Thus, the tooling of application modeling and data modeling should support model update capability. For example, changes in class model can be updated and reflected in LDM either through automated (for simple changes) or manual (where complex heuristics are required) methods for model convergence, and vice versa from LDM to class model. In reality, it is not an easy task to manage the synchronization and change management of class models and LDMs as they reside in different tools and are often performed by two distinct roles – the Application Modeler and the Data Modeler. Nevertheless, careful planning, excellent communication and disciplined change management can effectively utilize the tooling features and achieve end-to-end data governance.There are two use cases in the meet-in-the-middle scenario, depending on if you want to update your class models or LDMs:

1. Once class models are transformed into LDMs and used in RDA, the Application Modelers make some changes in the class models such as adding new properties. We want to update the LDMs in RDA to reflect the updated class models. This use case is an extension of the top-down scenario, with the added complexity of synchronizing existing LDMs in RDA with the new or modified information.

The steps in the first use case are:

1. The Data Modeler uses LDM version 1 in RDA, which was previously transformed from class model version 1 in RSA.

2. The Application Modeler modifies class model version 1 in RSA, then transforms the updated class model (version 2) as LDM version 1+.

3. The Data Modeler accesses and imports LDM version 1+ in RDA.

4. The Data Modeler compares and merges LDM version 1+ and version 1 into LDM version 2 in RDA.

7 - 46

Figure 5. Meet-in-the-middle Scenario – Application Modeling to Data Modeling

The following diagram shows the interaction between the Application Modeler and the Data Modeler in the first use case:

Once the LDMs are transformed into class models and used in RSA, the Data Modelers make some modifications to the LDMs, such as adding new columns. You should update the class models in RSA to reflect the updated LDMs. This use case is very similar to the bottom-up scenario, with the added complexity of synchronizing existing class models in RSA with the new or modified information. The steps in the second use case are:

1. The Application Modeler uses class model version 1 in RSA, which was previously transformed from LDM version 1 in RDA.

2. The Data Modeler modifies LDM version 1 in RDA, then transforms the updated LDM (version 2) as class model version 1+.

3. The Application Modeler accesses and imports class model version 1+ in RSA. 4. The Application Modeler compares and merges class model version 1+ and version 1 into class

model version 2 in RSA.

7 - 47

Figure 6. Meet-in-the-middle Scenario – Data Modeling to Application Modeling

The following diagram shows the interaction between the Application Modeler and Data Modeler in the second use case:

Model TransformationsModel transformations are at the core of integrating application modeling with data modeling. In the top-down scenario discussed above, class models are transformed to logical data models using the UML-to-LDM transformation; in the bottom-up scenario, logical data models are transformed to class models using the LDM-to-UML transformation.

7 - 48

UML Class Model

A class model defines:

• Model and packages: these serve as the structural components and namespaces for other model elements. A package can contain packages, diagrams, classes, associations, association classes, and data types.

• Classes: they represent concepts within the system being modeled. Instances of the same class share common characteristics. A class has:

o Properties: descriptions of the characteristics of a class. A property has, among other things, a type that defines the type of value it can have.

o Generalizations: a class may have generalizations, as in, taxonomic relationships, between it and more general classes. The class is fully consistent with the more general class and contains additional properties.

• Associations: these represent semantic relationships between two classes that involve connections among their instances. In addition to the simple form of association, there are two additional forms:

o Aggregation: a form of association that specifies a whole-part relationship between an aggregate (a whole) and a constituent part.

o Composition: a form of aggregation with strong ownership of parts by the composite (whole) and coincident lifetime of parts with the composite. A part may belong to only one composite at a time.

• Association classes: an association class is an association that is also a class. An association class connects two classes and has properties.

• Data types: a data type is a descriptor of a set of values. Data types include: o Predefined primitive types: Boolean, Number, String, UnlimitedNaturalo User defined data types: primitive types or enumerations

Please refer back to Figure 1 for the sample class model.

7 - 49

RDA Logical Data Model

A logical data model defines:

• Packages: these serve as the structural components for other model elements. A package can contain packages, diagrams, entities, and domains.

• Entities: they represent concepts, events, persons, places, or thing about which information is kept. Instances of the same entity share common characteristics. Entities may be either independent or dependent. An entity whose instances cannot be uniquely identified without determining its relationship to another entity or entities is a dependent entity; otherwise, it is an independent entity. An entity has:

o Attributes: descriptions of the characteristics of an entity. An attribute has, among other things, a type that defines the type of value it can have.

o Primary key: an attribute or attributes that uniquely identify an instance of an entity o Generalization: an entity may have generalizations, i.e., taxonomic relationships, between it and

more general entities. The entity is fully consistent with the more general entity and contains additional attributes.

• Relationships: these represent connections, links, or associations between two entities. There are three kinds of relationships:

o Identifying relationship: a relationship whereby an instance of the child entity is identified through its association with a parent entity. The primary key attributes of the parent entity become primary key attributes of the child.

o Non-identifying relationship: a relationship whereby an instance of the child entity is not identified through its association with a parent entity. The primary key attributes of the parent entity become non-key attributes of the child.

o Many-to-many relationship: an association between two entities in which each instance of the first entity is associated with zero, one, or many instances of the second entity and each instance of the second entity is associated with zero, one, or many instances of the first entity.

• Data types: a data type is a descriptor of a set of values. Data types include: o Predefined data types: BINARY, BLOB, BOOLEAN, CHAR, CLOB, DATALINK, DATE,

DECIMAL, DOUBLE, FLOAT, INTEGER, INTERVAL, LONG, ROWID, SHORT, TIME, TIMESTAMP, VARBINARY, VARCHAR, XML

o User defined data types: atomic domains

Please refer back to Figure 2 for the sample logical data model.

7 - 50

Top-Down: Class Model to Logical Data Model

From the above discussions it can be seen that the UML class model and the RDA logical data model match each other very well in modeling constructs and semantics. As a result, transforming a class model to a logical data model generally is straightforward and incurs no information loss. Table 1 shows the mapping from a class model (source) to a logical data model (target). In the table it is worth noting:

• A class does not have primary key; it has an implicit OID (object identifier). This is transformed to a surrogate key.

• A simple association is transformed to a non-identifying relationship if either association end has a multiplicity of 0.1 or 1; otherwise it is transformed to a many-to-many relationship.

• A property may have class reference as type, which has identical semantics as an aggregation. A class reference is therefore transformed to a non-identifying relationship.

• Association class is a concept which does not exist in the logical data model. It is transformed to an entity and two relationships to preserve the semantics of association class.

Table 1. UML-to-LDM Mapping

7 - 51

Figure 7. Logical Data Model Generated by the UML-to-LDM Transformation

Figure 7 shows the target logical data model generated by the UML-to-LDM transformation using the sample class model in Figure 1. In comparing the source and target models, please note:

• A surrogate key (as in, Invoice ID for Invoice) has been generated for each entity.

• Key inheritance (as in, Invoice ID from Invoice to ProductInvoice) takes place for generalization.

• Key migration (as in, Invoice Id to invoiceInvoice Id from Invoice to InvoiceItem) takes place for composition.

• Key migration (as in, Invoice Id to mainInvoiceID from Invoice to Invoice) takes place for aggregation.

• For key migration, by default, the child foreign key attribute name is generated by prefixing the parent role name to the parent primary key attribute name.

7 - 52

The UML Logical Data Model Profile

Not all classes defined during application modeling necessarily relate to data modeling or have persistent data; similarly, not all primitive types or enumerations necessarily corresponding to data types required for data modeling or persistent data. The UML Logical Data Model Profile can be used to:

• Allow user control over what classes, primitive types, or enumerations to transform to a logical data model.

• Specify concepts important to logical data modeling but missing in UML including:

o Primary key attribute(s)

o User defined data types: more information than what can be specified with primitive types or enumerations

o Referential integrity: as in, parent delete rule

In essence, the UML Logical Data Model Profile enables a user to perform logical data modeling using UML in RSA.

7 - 53

Table 2. The UML Logical Data Model Profile

Table 2 shows the stereotypes and attributes provided by the Logical Data Model Profile. Please note:

• Enumeration or primitive types may be stereotyped as Domain. If so, additional information (as in, the base type) can be specified.

• Classes may be stereotyped as Entity. By default, they are persistent and do not use surrogate key.

• Properties are always stereotyped as Attribute. By default, they are not required.

• Properties may be stereotyped as PrimaryKey.

• Associations and association classes are always stereotyped as Relationship. If so, foreign key attribute names (in the form of primary key attribute name, foreign key attribute name pairs) and parent delete rule (NONE / RESTRICT / CASCADE / SET NULL / SET DEFAUL) can be specified. In the future, child delete rule can also be specified.

7 - 54

Table 3. UML-to-LDM Mapping with the Logical Data Model Profile

Table 3 shows the mapping from a class model (source) to a logical data model (target) when the Logical Data Model Profile is applied to the class model. It is worth noting:

• Only classes stereotyped as Entity are transformed to entities. By default, they are persistent and do not use surrogate key.

• Properties stereotyped as PrimaryKey are transformed to primary key attributes, in which case the generated attributes are required.

• For associations and association classes, if foreign key attribute names and parent delete rule are specified, they are used for the generated relationship. In the future, child delete rule, if specified, will also be used.

• Only primitive types / enumerations stereotyped as Domain are transformed to atomic domains.

7 - 55

Figure 8. Sample Class Model with the Logical Data Model Profile

Figure 8 shows the sample class model wit the Logical Data Model Profile applied. Please note:

• All primitive types have been stereotyped as Domain.

• All classes have been stereotyped as Entity.

• The ID attributes of Invoice and InvoiceItem have been stereotyped as PrimaryKey.

7 - 56

Fig. 9. LDM Generated by the UML-to-LDM Transformation with the LDM Profile

Figure 9 shows the target logical data model generated by the UML-to-LDM transformation. The source of the sample class model used in this transformation is from Figure 8. In comparing the source and target models, please note:

• No surrogate key has been generated. Instead, primary key attributes (the ID of Invoice and ID of InvoiceItem) have been generated.

• Key inheritance (the ID from Invoice to ProductInvoice) takes place for generalization.

• Key migration (the Invoice Id to ivoiceID from Invoice to InvoiceItem) takes place for composition.

• Key migration (the ID to mainID from Invoice to Invoice) takes place for aggregation.

• For key migration, by default, the child foreign key attribute name is generated by prefixing the parent role name to the parent primary key attribute name.

7 - 57

Bottom-Up: Logical Data Model to Class Model

Similar to the top-down transformation, transforming a logical data model to a class model generally is straightforward and incurs no information loss. Table 4 shows the mapping from a logical data model (source) to a class model (target).

Table4. LDM-to-UML Mapping

7 - 58

Figure 10. Class Model Generated by the LDM-to-UML Transformation

Figure 10 shows the target class model generated by the LDM-to-UML transformation. The source of the sample logical data model used in this transformation is from Figure 2. In comparing the source and target models, please note:

• Primary key information (the ID of Invoice) is lost in the class model since UML class model does not support the concept of primary key.

• Foreign key attributes (the invoiceID of InvoiceItem) are not transformed to the class model since they are generated by key migration in the logical data model and are not inherent to the model.

7 - 59

Table 5. LDM-to-UML Mapping with the Logical Data Model Profile

In order to preserve logical data modeling concepts and information in the target class model, the Logical Data Model Profile can be applied to the target class model during the LDM-to-UML transformation. Table 5 shows the mapping from a logical data model (source) to a class model (target) with the Logical Data Model Profile applied. Please note:

• Entities are transformed to classes stereotyped as Entity.

• Primary key attributes are transformed to properties stereotyped as PrimaryKey.

• Atomic domains are transformed to primitive types and enumerations stereotyped as Domain.

7 - 60

UML Model Generated by the LDM-to-UML Transformation with the LDM Profile

Figure 11 shows the target class model generated by the LDM-to-UML transformation, with the Logical Data Model Profile applied to the target class model. The source of the sample logical data model used in this transformation is from Figure 2. In comparing the source and target models, please note:

• Primary key information (the ID of Invoice) is preserved in the class model.

• Foreign key attributes (the invoiceID of InvoiceItem) are not transformed to the class model since they are generated by key migration in the logical data model and are not inherent to the model.

Figure 11. UML Model Generated by the LDM-to-UML Transformation with the Logical Data Model Profile

7 - 61

Conclusion

This article provides a high-level overview of RSA and RDA and their integration. You viewed three integration scenarios and learned adoption criteria for the top-down scenario and the bottom-up scenario, respectively. In order to create well-formed application models and data models, it is not enough just to know how to use the tooling. It is equally important to know the reasons for adopting a certain scenario, to define a robust and repeatable change management process, and to create a strategy that leverages the synergy between application modeling and data modeling. Successful integration of application modeling and data modeling may require organizational and cultural changes as well. Hopefully, this article will help you jump-start your integrated application modeling and data modeling efforts.

The article also provides a detailed discussion of the UML-to-LDM and the LDM-to-UML transformations as well as the UML Logical Data Model Profile. In general it is beneficial to apply the Logical Data Model to the class model whether the class model serves as a source or is generated as a target. In the formal case, it allows a user to control what classes, primitive types, or enumerations to transform to a logical data model, and to specify concepts and information important to logical data modeling but missing in UML. In the latter case, it makes the transformation reversible since major logical data modeling concepts and information are preserved in the generated class model.

As Figure 12 illustrates, logical data modeling is the lynch pin of data modeling integration. You saw in this paper how application modeling in RSA can be integrated with logical data modeling in RDA. Integration between logical data modeling and relational data modeling is a standard feature of RDA. Integration between business modeling in WBM and logical data modeling in RDA, as well as integration between logical data modeling and XML data modeling in RDA, are already in the works and will be discussed in a forth-coming developerWorks article.

7 - 62

Figure 12. Logical Data Modeling as the Lynch Pin for Data Modeling Integration


Module 8 : Traceability

8 - 2

After completing this module, you will be able to:Ensure that solutions are connected to requirements (in other words, traceability) Create traceability to IBM® Rational® RequisitePro®

Create traceability to IBM® WebSphere Business ModelerUse topic and browse diagram to investigate traceabilities.

Module Objectives

8 - 3

Traceability

Traceability answers key questions in development, such as:

What requirements is this part of the design based on?Why did this (feature, use-case, subsystem, class) get implemented this way?What are the non-functional requirements for this design ?"What is the impact of changing a requirement?What happens to the solution if the business process is changed?

?

8 - 5

Product Integrations with Rational Software Architect

Rational Software ArchitectIBM®

WebSphere®

Integration Developer

UML (contract)BPEL

WSDL

one-way flow

BPEL has onlystuff that isto be automated

WebSphere Business Modeler

IBM® WebSphere®

Business Monitor

RequisitePro

IBM® WebSphere®

Application Server

IBM® WebSphere®

Process Server

RUNTIME

8 - 6

Comments

RequisitePro provides a powerful way to manage requirements and use cases to promote better communication, enhance teamwork, and reduce project risk. RequisitePro is integrated with Rational Software Architect to allow you to link development artifacts and requirements, and to demonstrate traceability from one to the other.

Modeling tools are useful in designing and building choreographed business processes. WebSphereBusiness Modeler models define the interfaces between processes, which are the contract for design and implementation. Rational Software Architect integration with WebSphere Business Modeler supports this business-driven, contract-based design and construction.

IBM® WebSphere® Studio Application Developer Integration Edition V5.1 is optimized for developing applications that deploy to IBM® WebSphere® Business Integration Server Foundation (WBISF) V5.1. WebSphere Studio Application Developer delivers a next-generation composite application development environment for building service-oriented applications that extend and integrate your existing IT assets.

In addition to a full J2EE development environment, WebSphere Studio Application Developer Integration Edition V5.1 provides easy-to-use tools for creating reusable services out of a variety of back-end systems, and for choreographing the interactions between those services using Business Process Execution Language for Web services (BPEL).

8 - 7

Traceability from Requirements to Design

Needs

SoftwareRequirements

Design User Doc

Features

Solution Space

Problem Space

Traceability

ProblemProblem

The system to be built

Test Procedures

8 - 8

Rational RequisitePro IntegrationRational RequisitePro

A requirements management tool Enables you to track relationships between requirementsProvides functionality to analyze the impact of changes to requirements

The Requirements perspective in Rational Software Architect:

Provides an effective interface to requirements managed in RequisitePro, including:

Documents – Vision, use-case specifications

RequirementsRequirement PropertiesViews

Allows requirements to be traced to model elements

Features and Vision

Vision Document

FEAT 1

FEAT 3

All Features

Use Cases

FEAT 7

8 - 9

Views of the Requirement Perspective

RequirementExplorer

Requirements Trace

Link Clipboard

Requirements Properties

Query ResultsRequirement Link Problems

8 - 10

RequisitePro

Requirements Explorer Query Results

8 - 11

Associating Requirements and Model Elements

Associating with an existing element

Drop a requirement on to an existing model element to associate that element with the use case in RequisitePro.

You can associate requirements with use cases, classes, diagrams, and relationships (associations, messages, and so on).

Drop a requirement on to an existing model element to associate that element with the use case in RequisitePro.

You can associate requirements with use cases, classes, diagrams, and relationships (associations, messages, and so on).

Creating a new model element

Drag a requirement to a diagram to create a model element in themodel that is linked to the requirement in RequisitePro. By default, use-case requirements create use cases in the model, all other requirements create classes.

Drag a requirement to a diagram to create a model element in themodel that is linked to the requirement in RequisitePro. By default, use-case requirements create use cases in the model, all other requirements create classes.

8 - 12

Comments

If use cases have been written, but model elements to represent them have not been created in Rational Software Architect, you can drag the use case requirements onto a diagram to create a use case model element.

If other requirement types are dragged on to a diagram, a class is created by default.

You may create a mapping between requirement types and model element types by modifying the properties of the RequisitePro project in the Requirements Explorer.

Consider carefully what traces should be established and maintained between model elements and requirements:

• Creating traces adds maintenance overhead, but with the right balance, the quality and timeliness of change impact analysis can be greatly improved.

• Consider associating architectural and major design elements to those requirements that, if changed, may result in a major impact to the system (and project).

8 - 13

Associating Requirements and Model Elements

When a requirement is dropped onto a model element, a proxy is created for the model element in RequisitePro.

Use cases are always directly linkedProxies are RequisitePro requirementsMapping between model elements and requirement types are managedusing the RequisitePro project propertiesAdditional attributes may be added to the proxy requirement types.

8 - 14

Comments

Linking requirements and model elements enhances Rational Software Architect. You can extend your requirements and model elements with the following capabilities:

• Associate requirements with model elements quickly by dragging artifacts between views. • Create associated requirements and model elements quickly by dragging artifacts between views. • Navigate to, and view, associated artifacts. • Manage your model elements with attributes, such as priority and status, in RequisitePro.• Establish traceability to requirements to indicate dependencies, and ensure that your design satisfies

your project requirements. • Monitor the impact of change within your project. • Develop use cases in RequisitePro and model them in Rational Software Architect, showing interaction

with actors and other use cases. • Change the name and text of a use case in either tool, and synchronize the use-case artifacts based on

rules, which you can configure.

8 - 15

Given:Existing RequisitePro project

Complete the following tasks:Explore Requirement PerspectiveLink Folders and Files to RequirementsLink UML Model Elements to RequirementsLink Java Classes to RequirementsReview Requirements

To begin the lab:



Expand DEV396 Labs, then select Lab 19: Create Traceability Links.

Follow the instructions indicated in the cheat sheet.

Lab 19: Create Traceability Links

8 - 16

WebSphere Business Modeler People who know the business create the models

Model Resources, roles, organization information, business metricsEnables teamwork, communication, versioning and Web publication

Clean Hand-off to ITBusiness modeling is the starting point for rapid and accurate IT process deployment and application development

8 - 17

WebSphere Business Modeler and Rational Software Architect

1. Business analyst creates business model

2. Software Architect views business model as UML

3. Requirements analyst gathers requirements based on business model

4. Software Architect creates UML design model

5. Software Architect references UML view of Business Process Model from UML design model

6. Software Architect creates design in UML then implementation in code

WebSphere Business Modeler

RationalSoftwareArchitect

UML DesignModel

Business ProcessModel

View as UML Contract

Business Process models serve as contracts for software

implementation of roles / tasks

Business Process models serve as contracts for software

implementation of roles / tasks

8 - 18

Business Process Model Elements

Process diagram generated by WebSphere Business Modeler

Stop NodeDecision

Task

Control flow

Business Item

Alternate paths

Annotation

8 - 19

Business Processes to Business Use Cases

WebSphere Business Modeler models can be opened in Rational Software Architect

Business model elements are automatically translated to UML elements

Business Processes in WebSphere Business Modeler

Business Use Cases in Rational Software Architect

8 - 20

Business Processes

In Rational Software Architect, a business process maps to:

A use case and realization (black box) viewAn activity diagram (white box) view

8 - 21

Mapping Business Items to Classes

Business Entities in Rational Software Architect

Business Item in WebSphere Business Modeler


Module 9 : Dexis Case with UML

Cas Dexis: Octroi de prêts par un organisme bancaire

Enoncé La banque Dexis souhaite réorganiser ses activités liées à l'octroi de prêts afin de rendre celles-ci plus performantes et plus équitables. La direction de la banque espère que, suite à cette réorganisation, les demandes de prêts augmenteront au minimum de 0,75% l’année suivante. Elle espère également attirer de nouveaux clients et renforcer son image. Le client d’une agence de la banque Dexis doit soumettre sa demande de prêt au service client en indiquant le montant qu'il souhaite emprunter, la durée, le motif du prêt ainsi que des renseignements généraux tels que son nom, son adresse et son revenu mensuel. Il s’attend à ce que le service de Dexis soit professionnel et de qualité. Le service client de l'agence constitue un dossier avec les différents renseignements et le transmet au service crédit du siège de la banque pour des objectifs de centralisation des dossiers de prêt. Les clients souhaitent que cette transmission se fasse de manière la plus confidentielle qui soit. Un même dossier peut traiter de plusieurs prêts à condition que le client soit le même pour tous les prêts du dossier. Le service crédit décide de l’acceptation ou du refus des prêts. Il examine chaque dossier en détail, en vérifie les informations et décide sur base du revenu mensuel et du motif du prêt de refuser la demande ou de l'étudier de façon plus approfondie. Le service crédit prend sa décision sur base de normes strictement édictées par le service juridique du siège de la banque. En cas de problème, le préposé peut demander l’avis du service juridique de manière à motiver correctement sa décision. Le service crédit peut aussi s’enquérir auprès du service placements des avoirs du client à condition que le service juridique de la banque ne soit pas opposé à ce transfert d’information. Dans le cas d’une étude plus approfondie, le service crédit émet une demande de renseignements auprès du service d'information. Ces renseignements portent d'une part sur le passé du client à l’occasion du remboursement d'éventuels prêts antérieurs et d'autre part sur l'identité du client, son revenu mensuel, ... Contrairement au service crédit, le service d’information a une liberté totale pour la réalisation de ses objectifs à condition toutefois d’observer les lois sur la protection des données et de la vie privée. Le service crédit s’attend à ce que les renseignements demandés soient les plus exacts et objectifs possible. Il vérifie également que le dossier est bien transmis dans son entièreté. Dans l'attente de ces informations, le service crédit établit un premier plan de financement, comportant: le taux à appliquer, le montant et la durée du prêt. Quand il a reçu la réponse du service d'information, il peut soit refuser la demande soit formuler une ou plusieurs propositions à présenter au client. Les propositions sont jointes à la demande qui retourne à l'agence. A la réception du dossier, la direction de l'agence examine les propositions avec le client: soit le client accepte une des propositions, soit il n'en accepte aucune, soit il en accepte une sous réserve de modifications (modification de la durée, diminution du montant emprunté, ...). Dans ce dernier cas, la direction de l’agence établit avec le client une nouvelle proposition qui tient compte des changements demandés.

9 - 2

9 - 3

Une proposition de prêt acceptée par le client doit encore être approuvée par la direction de la banque. Celle-ci s'occupe des dossiers de prêt en fin de semaine ou lorsqu'elle en a au moins 20 en attente. L’approbation ou le refus de la direction se concrétise par une note (accord ou refus) reprenant la date courante, le numéro du dossier et la raison (en cas de refus). Ensuite les dossiers approuvés retournent en agence où ils donnent lieu à l'établissement du contrat de prêt. En cas de refus, le client peut s’adresser directement au service juridique de Dexis et demander un complément d’information ou une enquête interne s’il estime avoir été lésé. Si la décision ne lui convient toujours pas, il peut aussi s’adresser à l’ombudsman attaché à la direction de Dexis. On connaît le nom, l'adresse, le salaire mensuel d'un client et les prêts qu'il a déjà éventuellement obtenus auprès de la banque Dexis ou d'une autre institution financière ainsi que, pour chacun de ceux-ci, la façon dont il a remboursé (régulier, tardif, mauvais). On connaît également les demandes de prêt qu'un client a déjà éventuellement émises auprès de la banque Dexis et, si elles ont été acceptées, les différentes propositions auxquelles elles ont donné lieu. Une demande de prêt comporte les renseignements suivants : montant demandé, durée demandée, date d'introduction de la demande et motif du prêt, taux souhaité, plan de remboursement souhaité. A condition que le client ou le notaire ne s’y opposent pas, les données du notaire sont aussi utiles à l’établissement du dossier. Le client peut aussi référencer certaines personnes en vue de garantie. La direction de l’agence secondée du service d’information vérifie ces informations pour le service crédit chargé d’accepter ou de refuser le prêt. Pour une institution financière, on connaît son nom, son type (banque, organisme privé, organisme public) et les différents prêts contractés par les clients de la banque Dexis auprès de cette institution. Pour chaque prêt, on connaît son numéro, son montant, sa durée, le client, l'organisme auprès duquel il a été contracté (si ce n’est pas la banque Dexis), le type d'échéance (mensuelle, trimestrielle, annuelle), les dates de début et de fin de remboursement, le taux d'intérêt et le montant à rembourser (montant prêté + intérêts). Pour des raisons légales, le remboursement doit faire l’objet d’un dossier de remboursement séparé du dossier de prêt. Il contient toutes les informations propres au type de remboursement et répertorie les problèmes de paiements, les intérêts de retard, les lettres de rappel, … Dans la base de données, on différencie les personnes qui sont ou non employés de Dexis. Une distinction est également faite entre types de clients (particuliers, indépendants, …). Une proposition de prêt est caractérisée par sa date, la durée et le montant du prêt proposé, le taux d'intérêt. On enregistre quotidiennement le taux d'escompte. Le taux d'intérêt est déterminé par la banque Dexis en fonction du motif, du montant et de la durée du prêt, ainsi que du taux d'escompte. Les valeurs des différentes informations relatives à un prêt sont nécessairement identiques aux informations correspondantes de la proposition qui lui a donné lieu (si elle existe).

Business Use-Case Diagram

9 - 4

Business Activity Diagram

9 - 5


9 - 6


9 - 7

Use-Case Diagram

9 - 8

Use-Case Diagram

9 - 9

Activity Diagram (page 1/2)

9 - 10

Activity Diagram (page 2/2)

9 - 11

Class Diagram

9 - 12

Composite Structure Diagram

9 - 13

Interaction Overview Diagram

9 - 14

Sequence Diagram

9 - 15


9 - 16

Sequence Diagram

9 - 17


9 - 18

Sequence Diagram

9 - 19


9 - 20

State Machine Diagram

9 - 21

State Machine Diagram

9 - 22

Component Diagram

9 - 23

Deployment Diagram

9 - 24


Module 10 : CARSID Case with RUP

10 - 2

Classical Waterfall DevelopmentClassical Waterfall Development

Achievement of sequential activitiesBased on too strong assumptions :

Requirements are all knowable in advanceRequirements have no high risk implicationsEnough calendar time…

Test

Analysis and Design

Implementation

Deployment

Requirementsanalysis

10 - 3

Iterative DevelopmentIterative Development

Resolves major risks before making large investments Enables early user feedback Makes testing and integration continuous Focuses project short-term objective milestones Makes possible deployment of partial implementations

T I M E

Iteration 1 Iteration 2 Iteration 3

DI

ADR

TD

IAD

R

TD

IAD

R

T

10 - 4

Iterative Development Produces a ReleaseIterative Development Produces a Release

Business Business ModelingModeling

RequirementsRequirements

Analysis & DesignAnalysis & Design

ImplementationImplementation

TestTest

DeploymentDeployment

Project Project ManagementManagement

Each iteration results in an executable release

AnchorAnchorPointPoint

MilestonesMilestones

10 - 5

RUP / UMLRUP / UML

StandardsStandards

UMLUML: 9 modelsmodels

RUPRUP: software project management

WebWeb ApplicationApplication Design Support

DataData basebase designdesign

ISOISO – i.e.•• 12207 : Software Life12207 : Software Life--cycle cycle processesprocesses

• 9126: Software Quality Characteristics & Metrics

• 9001 : Quality Management Systems, …

10 - 6

RUP : an Iterative Development ProcessRUP : an Iterative Development Process

Anchor Point Anchor Point MilestonesMilestones

10 - 7

Case Study : Case Study : CARSIDCARSID’’ss Coking PlantCoking Plant

CARSIDCARSID (Carolo-Sidérurgie) Duferco - Usinor (60/40)

Ex-Cockerill Sambre in Marcinelle-Marchienne

Steel, coke, sinter charge, cast iron, slabs.

CARSID Database re-organization

MigrationMigration, integrationintegration, new information system strategy

Knowledge management, continuation, training

ITIT projectproject managementmanagement andand methodologymethodology

Standardized/open modelling techniques (UML/RUPUML/RUP)

WebWeb Online,Online, IntranetIntranet andand EE--CommerceCommerce exploitationexploitation

10 - 8

CokerieCokerie

Marchienne

AgglomAggloméérationration

Marcinelle

Marcinelle

HautHaut--fourneaufourneau

4

AciAciéérierie

Marcinelle

Four Four éélectriquelectrique

Marcinelle

WorkflowWorkflow

Marcinelle

CoulCouléées continueses continuesbramesbrames

MMéétallurgie tallurgie de pochede poche

Marcinelle

10 - 9

SchemaSchema

10 - 10

K DTOUR DE

STOCKAGECHARBON

C1 C2

TOUR EXTINCTION

1GC1 2GC2

D1

2GC1 réserve1GC2 Réserve

RéserveC3 LC1C4 LC3

E1New2000

D2Réserve

D3

E2

Coking Coking ovensovens and Toolsand Tools

10 - 11

Coking PlantCoking Plant

10 - 12

LoadingLoading

10 - 13

DeloadingDeloading

10 - 14

CoolingCooling

KOPPERSDIDIER

Silos de stockage des charbons

MAGASINATELIERS

E.L.M.

DOSAGE CHARBONS (MELANGE)

BROYAGE MELANGE

DECHARGEMENT FADS

MEYERTP1 TP2 TP3

TP5

TP4

TP6

TP7

Mélange àbroyer

Mélange broyédestiné aux

fours

TOUR DESTOCKAGE

COPPEE ICOPPEE II

F O U R S F O U R S

TP8

Stocks de charbons

BASCULE

HALLANCIEN

T900

Mélange broyédestiné aux

fours

BUREAUX

10 - 16

transfert charbon silo

équipe FADS

réception réserve

réception charbon

réception fads

cuisson

équipe four

équipe préparation

mélange

approvisionnement tour à charbon

Tour_à_Charbon(f rom Logical View)

chargement enfourneuse

<<extend>>

criblage du coke

refroidissement

Enfourneuse(f rom Logical View)

Coke_Car(f rom Logical View)

enfournement

<<extend>>

défournement<<extend>>

Guide_Coke(f rom Logical View)

Four(f rom Logical View)

inversionmesurage t°réglage

équipe réglage

UML / UML / waterfallwaterfall : Use Case : Use Case DiagramDiagram

Coking Coking

Requirements AnalysisRequirements Analysis

10 - 17

UML / UML / waterfallwaterfall : : ActivityActivity DiagramDiagram

réception du brut

contrôler le charbon

transporter le brut

réceptionner le brut

transférer au doseur

(remplissage du magasin)

doser le mélange

stocker le brut

(remplissage du doseur)

(arrivée d'un train, bateau ou camion)

transporter le mélange

(mélange d isponible)

(mélange non disponible)

broyer le mélange de brut

réceptionner et stocker la pâte

approvisionner l'enfourneuse

(tour chargée en pâte)

recharger

(enfourneuse alignée et ouverte)

fournir la pâte au four

(enfourneuse pleine)

cuire la pâte

vider le four

(cuisson terminée)

égaliser la charge du four

pousser la charge de saumon

diriger la charge

prendre la température et le profil

réceptionner le saumon

transporter au refroidissement

transporter et déversr la charge au criblage

transporter au quai d'attente

éteindre le saum on

( coke car aligné à la tour d'extinction )

(charge d 'eau déversée)

laisser se refroidir la charge

(coke car a ligné à l'a ire à coke)

arroser

(saumon éteint)cribler le coke

(coke car aligné au criblage)

(temps de refroidissement écoulé)

(saumon non éteint)

(saumon éteint)

( coke criblé )

(four rempli et fe rmé)

(Brut en silo)

(métaux retirés)

(transferts débutés)

(mélangé, broyé et transporté)

(coke car chargé de coke)

cribleur : Criblageaire : Aire_a_Coketour : Tour_Extinctioncar : Co ke_Carguide : Guide_Cokedéfourneuse : Défourneusefou r : Fou renfourneuse : Enfo urneusetour : Tour_à_Charbonbroyeur : Broyeurbande : Bande_Broyeursilo dos : Silo_Doseursilo mag : Silo_Magasinbande : Bande_Transporteusedétecteur : Detecteur_Overbandstock_charbon : Stock_Charbon

Cooking ProcessCooking Process

Requirements Analysis

10 - 18

UML / UML / waterfallwaterfall : : ActivityActivity DiagrammeDiagramme

transporter au refroidissement

transporter et déversr la charge au criblage

transporter au quai d'attente

éteindre le saumon

( coke car aligné à la tour d'extinction )

(charge d'eau déversée)laisser se refroidir la

charge

(coke car aligné à l'aire à coke)

arroser

(saumon éteint)cribler le coke

(coke car aligné au criblage)

(temps de refroidissement écoulé)

(saumon non éteint)(saumon éteint)

( coke criblé )

Cooling Process Cooling Process

10 - 19

guide coke à mesure

Positionable

Planning_d

def ournement_en_cours : Def ournement

def ournement_suiv ant()optimiser()

C oke_Car

puissance : Integeralimentation : Variant

est-v ide()réceptionner_mp()aligner_tour()aligner_cribleur()aligner_aire()dev erser_coke()

Tour_Extinction

Niv eau_eau : Integer

dév erse_charge()est_libre()reserv oir_plein()

0..1

0..2

0..1

0..2

éteint saumon

Déf ourneuse

nom : String

puissance : Integeralimentation : Variantplanning : Planning_ddéf ournement : Def ournement

ouv rir_f our()déf ourner()f ermer_f our()cherche_def ournement()v alidation_def ournement()ouv rir_trappe()égaliser_contenu_f our()f ermer_trappe()

0..20. .2

apporte saumon

Saumon

prof il : prof ilt em pérature (haut ) : Integert em pérature (milieu) : In tegert em pérature (bas) : In teger

0..1

0. .n

0..1

0. .n

0. .1

0..n

0. .1

0..n

0..1

0..n

0..1

0..n

Def ournement

date & heure planif iées : Datedate & heure ef f ectiv es : Datef orce : Force de déf ournementf our : Fourcoke_car : Coke carguide_coke : Guide cokedef ourneuse : Déf ourneusecause_non_respect_timing : Stringpression : Integer

encoder_cause()

1

0..1

1

0..1

0..n

0..n

1

0..n

1

1

0..n

1

0..n

correspond

1

0..n

1

0..n

correspond

EQ f our

0..2

0..4

0..2

0..4

0..1

0..4

0..1

0..4

0..n

1

0..n

1

prépare

0..3

0..4

0..3

0..4

0..40..4

0..1

0..n

0..1

0..n

0..n0..n

correspo

0..4

0..4

0..4

0..4

UML / UML / waterfallwaterfall : Class : Class DiagramDiagram

UnloadingUnloading

Analysis Analysis

10 - 20

: Four : équipe four

: Enfourneuse : Défourneuse

1: aligner(Four)

2: aligner(Four)

3: ouvrir( )

6: remplir_four(Pâte_à_coke)

7: égaliser_contenu_four( )

8: fermer( )

5: ouvrir_trappe(Fo...

10: fermer_trappe( )

4: ouvrir_bouches( )

9: fermer_bouches( )

UML / UML / waterfallwaterfall : : SequenceSequence / Collaboration/ Collaboration

10: réceptionner_mp(Saumon)

: équipe four

: Défourneuse

: Guide_Coke

: Coke_Car : Four

9: prendre_profil(Saumon)

11: fermer( )

5: ouvrir_four( )7: défourner( )

12: fermer_four( )

6: ouvrir_porte( )

13: fermer_porte( )

1: aligner(Four)

2: aligner(Four)

3: aligner(Four)

4: ouvrir( )

8: transférer_saumon(Saumon)

Loading Loading Unloading Unloading

DesignDesign

10 - 21

UML / UML / waterfallwaterfall : : StatechartsStatecharts

démarrage

actif-1300°C

attente enfournement

est enfourné

attente égalisation

cuisson

est égalisé

attente ouverture porte

attente defournement

défourné

attente enfournement

est enfourné

attente égalisation

cuisson

est égalisé

attente ouverture porte

attente defournement

défourné

inactif-700°C

enfourneuse.remplir_four() défourneuse.ouvrir_trappe()

défourneuse.égaliser_contenu_four()

défourneuse.fermer_trappe()

cuisson_terminée()

défourneuse.ouvrir_four()

guide_coke.ouvrir_porte()défourneuse.défourner()

activer()

défourneuse.fermer_four() and

guide_coke.fermer_porte()

désactiver()

OvenOven

Design Design

10 - 22

CARSID : RUP/Project ManagementCARSID : RUP/Project Management

Iterationpreliminary

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Deployment

Inception Elaboration Construction Transition

IterationsElab #1 Elab #2 Const #1 Const #2 Tran #1

Project management

(A)(A) (B)(B)

(C)(C)(D)(D)

(E)(E) (F)(F)

(G)(G) (H)(H)

(I)(I) (J)(J)

(K)(K) (L)(L) (M)(M) (N)(N)

(O)(O)

(P)(P)

(Q)(Q)

(R)(R) (S)(S)

(T)(T) (T)(T) (T)(T) (T)(T)

10 - 23

MS Project RUP / Project ManagerMS Project RUP / Project Manager

Wizards allow you to select how many iterations you want in each phase, as well as which discipline-based RUP activities you want in each iteration.

Wizards allow you to select how many iterations you want in each phase, as well as which discipline-based RUP activities you want in each iteration.

Wizards allow you to select what deliverables you want in each iteration, and to attach activities or roles to them.

Wizards allow you to select what deliverables you want in each iteration, and to attach activities or roles to them.

(T) Project Management (T) Project Management

10 - 24

Optimiser le planning des enfournements - défournements des pauses

Gèrer la production

Ingénieur de production

Gérer la cokerie

Management

Obtenir rapidement de bons rapports d'analyse des charbons

Fournir des informations de production de qualité

Coke de qualité

Améliorer les communications entre les travailleurs Améliorer l'analyse des données de pause

Collecter des informations de production de qualité

Améliorer l'extraction des données

<<support>>

<<support>>

<<support>>

Equipe FADS

Réception charbon

Equipe préparation

Tour à charbon

Mélanger charbon

Equipe réglage Equipe FourCokeCribler coke

Saumon de coke cuit

Défourneuse

Guide coke

Guider coke

Coke car

Eteindre coke

Tour d'extinction

<<support>>

<<support>>

Chargement enfourneuse

InversionGuide coke, coke car et défourneuse positionnés

Défournement

<<support>>

<<include>>

Cuisson

<<support>>

Enfournement<<support>> Enfourneuse

Enfourneuse positionnée

Four

(A) Iteration 1 : Elaboration(A) Iteration 1 : Elaboration


Business Business AnalystAnalyst (UC (UC DiagDiag))

10 - 25

Business/Syst. Business/Syst. AnalystAnalyst (UC (UC DiagDiag))

(C) Iteration 3 : Elaboration(C) Iteration 3 : Elaboration

Requirements Analysis Requirements Analysis

EnfourneuseE1

EnfourneuseE3

Management

Service informatiqueIngenieurs de production

Equipe reglage

Equipe mélangeBroyeuse

Encoder temperature carneaux

Enfourneuse

Mélanger charbon

Guide Coke

Defouneuse

Cuisson

<<extend>>

Four

Equipe controle

Enfournement

<<extend>>

<<extend>>

Defournement

<<extend>>

Contremaitre

Utilisateur

Encoder Cahier Electronique

Creer planning defournement

<<extend>>

<<extend>>

Utiliser intranet

<<include>>

<<include>>

Rechercher Information

<<include>>

Chercheur d'informations

transfert charbon silo

équipe FADS

réception réserve

réception charbon

réception fads

cuisson

équipe four

équipe préparation

mélange

approvisionnement tour à charbon

Tour_à_Charbon(f rom Logical View)

chargement enfourneuse

<<extend>>

criblage du coke

refroidissement

Enfourneuse(f rom Logical View)

Coke_Car(f rom Logical View)

enfournement

<<extend>>

défournement<<extend>>

Guide_Coke(f rom Logical View)

Four(f rom Logical View)

inversionmesurage t°réglage

équipe réglage

(B) Iteration 2 : Elaboration(B) Iteration 2 : Elaboration


10 - 26

Business Business ProcessProcess AnalystAnalyst ((ActAct DiagDiag))

Mise en si lo du c harbon

Calculer les mélanges

Racler les charbons

Mélanger

Transporter le mélange

Broyer

Analyser mélange charbon

Rapporter les résultats de l'analyse dans l'intranet

LaboratoireBroyeuseTapi s ro ula ntEquipe mélange

réception du bru t

contrô ler le ch arbo n

transporter le b rut

réceptionner le bru t

trans férer au doseur

(rem plissage du m agas in)

dos er le mé lange

s tocker le brut

(rem pliss age du doseur)

(arrivée d 'un train, bateau ou cam ion)

transporter le méla nge

(méla nge d ispo nible )

(m élange non disponible )

broyer le m élange de bru t

réceptionner et s tocker la pâte

approvis ionner l 'enfourneus e

(tou r chargée e n pâte )

recharger

(enfourneuse al ignée et ouverte)

fournir la pâ te au four

(enfourneus e p leine)

cu ire la pâ te

vider le four

(cuisson term inée)

éga lis er la charge du four

pousser la charge de saum on

diri ge r la charge

prendre la tem pérature e t le p rofil

réceptionner le sau m on

trans porter au refroidis sem ent

transporter et dévers r la charge au crib lage

trans porter au qua i d 'atten te

éteindre le s aum on

( coke car al igné à la tour d'extinction )

(charge d 'eau déversée)

lais ser se re froidir la charge

(coke car a ligné à l 'a ir e à coke )

arroser

( sau mon étein t)cribler le coke

(coke car aligné au crib lage)

(tem ps de refroid iss em ent écoulé)

(saum on non é teint)

(sau mon é teint)

( coke criblé )

(fou r rem pli e t fe rm é)

(Brut en s i lo)

(m étaux re tirés )

(trans ferts débutés)

(m élangé, broyé e t transporté)

(coke car chargé de coke)

cribleur : Criblageaire : Aire_a_Coketour : Tour_Extinctionc ar : Co ke_ Carguide : Guide_Cokedéfourneuse : Défourneusefou r : Fou renfourneus e : Enfo urneusetour : Tour_à_Charbonbroyeur : Broyeurbande : Bande_Broyeursilo dos : Silo_Doseursilo mag : Silo_Magasinbande : Bande_Transporteusedétecteur : Detecteur_Ov erbandstock_charbon : Stock_Charbon

(D) Iteration 1 : Inception (D) Iteration 1 : Inception


(E) Iteration 2 : Elaboration(E) Iteration 2 : Elaboration

RequirementsRequirements

Fin de la cuisson

Alignement du guide coke

Pousse le coke

dans le coke car

Alignem ent de la déf ourneuse

Alignem ent du coke car

Mise en place de l'auge mobile du co ke car

Ouv erture des por tes

Ferm eture des portes

Relev é de la tem pérature, de la puissance et du prof il coke

Val id er le déf ournem ent

Four v ide

ContremaîtreCoth ermFou r à cokeCo ke carDéfou rneuseGu ide coke

Mélange dans la tour a charbon

Chargement de l'enfourneuse

Ouverture des mamelles de remplissage

Scellé des mamelles

Positionnement au-dessus du four

Alignement IPOVECO

Remplissage du four

Repalage

Enregistrement des données relatives à l'enfournement

Valider l'enfournement

ContremaîtreBa se de donnéesDéfourneuseEnfourneuseEquipe enfour nementTour à charbon

10 - 27

System System AnalystAnalyst (Class (Class DiagDiag.).)

Locom ot ive

Num Loco : Long

G roupLoco

Num er o : Long

1

1. . n

1

1. . n

conduit

Tender

Tender : Long

0. . 1

0. . n

0. . 1

0. . n

accompagne

PlacePr oduct ion

Code : St r ing

AnalyseChar bon Q uant it e : Long

AnalyseM elange

Q uant it e : Long

AnalyseCokeQ uant it e : Long

Sales

Poids : LongDat eTim e : Dat e

RecapPauseCoPr oduit

DhPause : Dat eExt r act eur Nor d : SingleExt r act eur Sud : SingleVit esseNor d : SingleVit esseSud : SingleDebit Nord : SingleDebit Sud : SingleTem perat ur eVolut eNor d : SingleTem perat ur eVolut eSud : SingleAm per ageNor d : SingleAm per ageSud : SingleRegulat ionNor d : St r ingRegulat ionSud : St r ingVanneRappoldNor d : St r ingVanneRappoldSud : St r ingPr essionHuileEnt r eeNor d : SinglePr essionHuileEnt r eeSud : SinglePr essionHuileSor t ieNor d : SinglePr essionHuileSor t ieSud : SingleVibr at ionHor izont aleNor d : SingleVibr at ionHor izont aleSud : SingleVibr at ionVer t icaleNord : SingleVibr at ionVer t icaleSud : SingleTem perat ur eExt er ieur eNor d : SingleTem perat ur eExt er ieur eSud : SingleCondensat ionDebit : SingleCondensat ionAnalyse : SingleLavageDebit : SingleLavageAnalyse : SingleCSFDebit : SingleCSFAnalyse : SingleBiologiqueDebit : SingleBiologuiqueAnalyse : SingleVent ur iDebit : SingleVent ur iTem per at ure : SingleVent ur iPh : SingleBr igadier : St r ingO per at eur : St r ingO per at eur G azomet r e : St r ingI t iner ant Copr oduit : St r ingI t iner ant BioG azomet r e : St r ingChaguerG our don : St r ingHor sQ uot a : St r ingTem pSor t ieCTH1 : SingleTem pSor t ieCTH2 : SingleTem pSor t ieCTH3 : SingleTem pSor t ieCTH4 : SingleTem pSor t ieEG R1 : SingleTem pSor t ieEG R2 : SingleTem pSor t ieEG R4 : SingleTem pSor t ieEG R3 : SingleTem pEnt r eeLaveur5Nor d : SingleTem pEnt r eeLaveur5Sud : SingleTem pEnt r eeLaveur1Nor d : SingleTem pEnt r eeLaveur1Sud : SinglePr essionEt Debit Vapeur : St r ingNiveauRes500 : SingleNiveauResB500 : SingleNiveauRes1000 : SingleNiveauRes800 : SingleNiveauRes6514 : SinglePost eEmet t eur : St r ingDet ect eur CO : St r ingCom m ent air e : St r ingSignat ureBr igadier : St r ingCom m ent air eO perat eur : St r ingSignat ureO per at eur Technique* : St r ingVolum eResFuel6509 : SingleHaut eurResFuel6509 : SingleVolum eResFuel6508 : SingleHaut eurResFuel6508 : SingleVolum eResFuel6511A : SingleHaut eurResFuel6511A : SingleVolum eResFuel6511B : SingleHaut eurResFuel6511B : SingleLaveur 1Nor dDebit : SingleLaveur 1Nor dPassage : SingleLaveur 1SudDebit : SingleLaveur 1SudPassage : SinglePer t eFuel : SingleHaut eurSoudeAvant : SingleHaut eurSoudeApr es : SingleConsomm at ionSoude : Single

M esur eSynchr oneBat t er ieM inut e

Dh_M esure : Dat eV001 : I nt egerV077 : I nt eger

M esur eSynchr oneDiver sJour

Dh_Mesur e : Dat eV001 : I nt egerV065 : I nt eger

M esur eSynchr oneDiver sM inut eDh_M esure : Dat eV001 : I nt egerV106 : I nt eger

M esureSynchr oneDiver sPause

Dh_M esur e : Dat eV001 : I nt egerV100 : I nt eger

RecapPauseFourDhPause : Dat eNomAjust eur : St r ingComm ent air eAjust eur : St r ingSignat ur eAjust eur : St r ingNomElect r ician : St r ingComm ent air eElect r ician : St r ingSignat ur eElect r ician : St r ingNomCont r em ait r e : St r ingAssist ant Cont rem ait r e : St r ingComm ent air eCont r em ait re : St r ingSignat ur eCont rem ait r e : St r ingNbr eDef our nement Coppee : SingleNbr eDef our nament Koppers : SingleNbr eDef our nament Didier : SingleEt at CuissonCoppee : St r ingEt at CuissonKopper s : St r ingEt at CuissonDidier : St r ingPlat eauCoppeeNet t oyeCot eCoke : St r ingPlat eauKopper sNet t oyeCot eCoke : St r ingPlat eauDidier Net t oyeCot eCoke : St r ingPlat eauCoppeeNet t oyeCot eM achine : St r ingPlat eauKopper sNet t oyeCot eM achine : St r ingPlat eauDidier Net t oyeCot eMachine : St r ingTpsExt inct ionEnSeconde : I nt egerTpsEgout t ageEnSeconde : I nt egerTpsExpedit ionCK16EnM inut e : I nt egerPompeEnSer vice : St r ingCokecar EnSer vice : St r ing

RecapJour CoPr oduitDhJour : Dat eVolum eRes2G oudr on : I nt egerVolum eRes3G oudr on : I nt egerVolum eRes4G oudr on : I nt egerVolum eRes5G oudr on : I nt egerVolum eRes6G oudr on : I nt egerVolum eRes7G oudr on : I nt egerVolum eRes8G oudr on : I nt egerVolum eRes9G oudr on : I nt egerVolum eRes10G oudr on : I nt egerCpt eur FuelVersCent r alAvant : I nt egerCpt eur FuelVersCent r alApr es : I nt egerLit r ageFuelVersCent r al : I nt eger

CamionCoPr oduit

NoPlaque : St r ing0. . * 0. . *0. . * 0. . *

Deplacer

Dh_Depar t G oud : Dat eRet our EauCam ion : BooleanType : St r ingFir m eEnt r eeFuel : St r ingHt eur Avant Ent r eeFuel : SingleHt eur Apr esEnt r eeFuel : SingleNoResEnt r eeFuel : SingleLit r ageEnt reeFuel : SingleHeur eEnt r ee : St r ing

Place

Name : St r ing

0. . n1 0. . n1

concer neTest 2 : St . . .

Liver eTest 2 : S. . .

Par t iciper

Test : St r ing

Def ournem ent _Cot her m

V 00 1 : I n teg erV 17 7 : I n teg er

Def our nam ent _Puissance

V001 : I nt egerV113 : I nt eger

Def our nem ent _Pr of ilCokeV001 : I nt egerV088 : I nt eger

M sgG r oupe

I d_G r oupM sg : I nt egerLibelleM sg : St r ingTypeM sg : St r ing

TCxSer ieTem pPyr om et r eNum Cx : I nt egerTem perat ur e : I nt eger

TcxTypeDeM esur e

I d_TypeDeMesur e : I nt egerLibelle : St r ing

M sgComm unicat ion

Aut eur : St r ingDh_Debut Af f ichage : Dat eDh_FinAf f ichage : Dat eCom ment air e : St r ingResponse : St r ing

1

0. . *

1

0. . *

1

0. . *

1

0. . *

Bassin

Bassin : LongLibelle : St r ing

Sit e

Sit e : LongLibelle : St r ing

0. . n

1

0. . n

1

G r anCokeQ uant it e : I nt eger

G r anMelange

Q uant it e : I nt eger

Usine

Usine : Long

0. . n

1

0. . n

1

Ser vice

Ser vice : L. . .Libelle : St r ing

0. . n

1

0. . n

1

TCxList eSer ieTem pPyr om et r eI d_Ser ie : I nt egerTypeDeG az : St r ingPCI : I nt egerDh : Dat ePyr omet r eur : St r ingRegleur : St r ingCom ment air e : St r ingValide : Boolean 1

0. . *

1

0. . *

1

0. . *

1

0. . *

M essageRejet e

I d_M sg : I nt egerDat eTr ait ement M sg : Dat eNum er oEr reur : I nt egerDescr ipt ionEr r eur : St r ingEm et t eur Msg : St r ingNum er oM sg : I nt egerLibelleM sg : St r ingSour ceEr r eur : St r ing10. . 1 10. . 1

PDef Par amet r e

I d : I nt egerDat eDer nier eM odif : Dat eCom m ent aire : St r ingDh_PauseEnCour s : Dat eTpsCuissonCoppee : I nt egerTpsCuissonKopper s : I nt egerDelaiEnt r eDef our nEt Enf our n : I nt egerEcar t M axTpsCuissonCoppee : I nt egerEcar t M axTpsCuissonKopper s : I nt egerEcar t Sur Pr ogr Toler eCoppee : I nt egerEcar t Sur Pr ogr Toler eKopper s : I nt egerDef ault DelaiEnt r eDef Et Enf : I nt egerModif DhM achineAut or isee : I nt egerDelaiEnSecondeDuRef r eshAut oI nt er f ace : I nt egerTim eO ut Execut eM odele : I nt egerNbr Heur eAvant PauseCour ant eAVisualiser : I nt egerNbr Heur eApresPauseCour ant eAVisualiser : I nt egerPasswor dO pt ion : St r ingAnim at ionVideo : I nt egerM_PV_Enabled : I nt egerM_PV_kdpapHS : I nt egerEnt r et ienHeur eM in : I nt egerEnt r et ienHeur eM ax : I nt egerEnt r et ienDureeM in : I nt egerEnt r et ienDureeM ax : I nt egerEnt r et ienPasM in : I nt eger

PlanningEnt r et ien

Dh_Debut : Dat eDur eeEnM inut e : I nt eger

ConsigneTem psCuissonI d_Consigne : I nt egerDh_Debut Changem ent : Dat eConsTpsCuis_Kopper sDidier : I nt egerConsTpsCuis_Coppee : I nt eger

PdelList eHeur ePour M odeleLightI d_Pr ogr : I nt egerHeur eFour : Dat e

Pdef DHPour Debug

DhM aint enant : Dat eDhAvant : Dat e

Per sonneI d_Per sonne : I nt egerPr enom : St r ingNom : St r ingDat eNaissance : Dat e

Pdef Nombr eFour Pr oduit

Dh_Pause : Dat eNbr eFourCopM odelise : I nt egerNbr eFourKDM odelise : I nt egerNbr eFourCopPr ogr amm e : I nt egerNbr eFourKDPr ogr amm e : I nt egerNbr eFourCopRealise : I nt egerNbr eFourKDRealise : I nt eger

Pdef Et at

Et at : I nt egerLibelle : St r ingSignif icat ion : St r ing

t ierscod t ie : . . .nom t ie : . . .adr t ie : . . .or i : St r ing

Tr anspor t eur

int er dit : St r ing

Fam _ar t iclef am _ar t : St r inglib_f am : St r ingor i : St r ing

Postpst _num : I nt egerdat _pst : Dat e

Four nisseur( f rom Concept ualM odelPck)

Client

( f rom Concept ualM odelPck)

Bascule

bas id : I n. . .bas : St r ing

Badge

num bad : . . .dat cr e : . . .dat m od : . . .t yp bad : . . .num pas : . . .pas m ax : . . .cod ina : B. . .ver com : . . .r ec bad : . . .r em : St r ingr em com . . .valide : Booder pes : . . .bad act : . . .

Voie

Voie : St r ingI ndexVoie : . . .Type : St r ingLibelle : St r ingO r ient at ion . . .SensPr iv : . . .Et at : St r ingLoungueur . . .CulDeSac : . . .

0. . n1 0. . n1

dans

Et at WagonEt at : St r ingLibelle : St r ing

TypeWagonTypeWagon : St r ingLibelle : St r ingCouleur : St r ing

Cat egChom age

Cat egChom age : St r ingLibelle : St r ing

TypeM at iere

TypeM at ier e : St r ingLibelle : St r ingCouleur : St r ing

Piedr oitI d_Pdt : I nt egerLibelle : St r ing

1

0. . *

1

0. . *

M essageTr aceChr onologiqueDat a

Dat eTr ait em ent Msg : Dat eEm et t eur M sg : Dat eNum er oM sg : Dat eNum er oSec : Dat eDh_Dat a : Dat eEnt et eM sg : St r ingDh_Pause : Dat eDh_Jour : Dat eDh_Mois : Dat e

1 0.. *1 0.. *

Bat t er ie

I d_Bat t er ie : I nt egerLibelle : St r ingI d_Pdt Debut : I nt egerNom : St r ingNum Four Deb : I nt egerNbr Four : I nt egerNbr Pdt : St r ing

1

0. . *

1

0. . *

0. . 1

0. . *

0. . 1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1 0. . *1 0. . *

1

0. . *

1

0. . *

PlanningPost e

I d_Cycle : I nt egerEquipe : I nt eger

10. . * 10. . *

Pdef List eResultI d_Result at : I nt egerDh_I dResult at : Dat eDh_Pause : Dat eTypeDeM odele : St r ingNom MachineClient : St r ingNom User : St r ingSt at usExecut ionModele : I nt egerDh_FinExecut eM odele : Dat eLibelleSt at us_FinExecut eM odele : St r ingCom ment air eResult at : St r ing

1

0.. *

1

0.. *

1

0. . *

1

0. . *

Pdef Result atDh_Def _Pr evue : Dat eEt at _Pr evu : I nt egerEt at _HS_Pr evu : I nt egerDh_Def _Pr evueCor r igee : Dat eEt at _Cor r ige : I nt egerEt at _HS_Cor r ige : I nt egerEnt r et ien : St r ingCom m ent air e : St r ingDh_Enf _Pr ec : Dat eDh_Def _M inimale : Dat eO per at ion : St r ing

1

0. . *

1

0. . *

Enf our nem ent _Diver s

V001 : I nt egerV100 : I nt egerDh_Pause : Dat eDh_Jour : Dat eDh_M ois : Dat e

Localit e

cod loc : . . .loc : St r ing

1

0. . *

1

0. . *

Cam ion

pla cam : . . .chg max : . . .t ar e : I nt . . .f r c t ar : . . .dat t ar : . . .der t ar : . . .

10. . 1 10. . 1

1

1. . *

1

1. . *

Ar t icle

cod_ar t : I nt egercod_env : St r inglib_ar t : St r inglibelle : St r ingor i : St r ing

1

1. . *

1

1. . *1

0. . *

1

0. . *

Comm ande

num com : I nt . . .ent _sr t : Boolean

1 1. . *1 1. . *

1

0. . *

1

0. . *

10. . *

10. . *

Pesee

num : I nt . . .Dat eTim e : . . .pesee1 : I . . .pesee2 : I . . .pes val : B. . .pes ann : . . .r em : St r ingr em sys : . . .st at us : S. . .lib pr e : St . . .cod pr e : . . .

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

E nt ete Mv t

Num M vt : LongTypeM vt : S. . .I nt er caler : . . .I nver sion : S. . .TypeM vt Sens . . .Dat eEnr eg : . . .Dat eDebut : . . .Dat eFin : Dat eVoieDespose : . . .SensDepose : . . .

Raccordem ent

RaccSncb : St r ingLibelle : St r ingRaccCklSam : Boolean

1. . n

1

1. . n

1

WagonNumWago. . .PoidsBr ut . . .Tar e : LongPoidsNet : . . .PoidsTheor . . .Longueur . . .Dat eTim eD. . .NumChass. . .

0. . n

1

0. . n

1

de t ype 2

0. . n 10. . n 1

de t ype

0. . n

0. . 1

0. . n

0. . 1

M at ier e

M at iere : . . .Libelle : St r ing 0. . n

1

0. . n

1

de t ype 1

Def our neuse

I d_Def ourneuse : I nt egerLibDef our neuse : St r ingI d_Engin : I nt egerPuissanceMaxim ale : I nt egerPuissanceCalculPad : I nt egerPuissanceCalculTG r : I nt egerCoef Cor r Mul : I nt egerCoef Cor r Add : I nt egerNbr SecondeEchant illonnage : I nt egerTpsM axDef our nam ent : I nt egerSur f aceRef : I nt eger

Four

I d_Four : I nt eger

1

1. . 2

1

1. . 2

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

PlanningDef our nem entDh_Def _Planif iee : Dat eDh_Def _Validee : Dat eDh_Enf _Validee : Dat eDh_Def _Mach : Dat eDh_Enf _Mach : Dat eDh_Enf _Pr ec : Dat eEt at : I nt egerEt at _Pr ec : I nt egerEt at _HS : I nt egerEt at _RP : I nt egerDh_Def _Cor r igee : Dat eDh_Enf _Cor r igee : Dat eJust if icat if : I nt egerCom m ent air e : St r ingEnt r et ien : St r ingFlag_Dh_Def _M ach_MajAPRESCCor r ect ion : I nt egerFlag_Dh_Enf _M achAPRESCor r ect ion : I nt eger

0. . *

0. . *

0. . *

0. . *

1

0. . 1

1

0. . 1

1

0. . *

1

0. . * 1

0. . 1

1

0. . 1

Enf our nem ent

Dh_Enf : Dat eDh_Enf _Diver s : Dat e

1

0. . 1

1

0. . 1

1

0. . *

1

0. . *

1

0. . *

1

0. . *

PlaceO f Char bon

( f r om Concept ualM odelPck)

Payscod_pay : I nt egerpay : St r ing

0. . n

1

0. . n

1

1

0. . *

1

0. . *

Bat eaux

Nom : St r ing

Livr aison

cod liv : I nt . ..lib_liv : St r ingor i : St r ing 0. . *0. . * 0. . *0. . *

0. . *

0. . *

0. . *

0. . *

10 .. 1 10 .. 1

M vt Det ail

Dat eTim e : D. . .Posit ion : I nt . . .Num LVoit : I . . .PoidsNet : LongPoidsBr ut : L. . .PoidsTheor ique . . .Tar e : LongSt at ut : St r ing

1

0. . n

1

0. . n

1 0. . n1 0. . n

1

0. . n

1

0. . n

1

0. . n

1

0. . n Def our nem ent

Dh_Def : Dat eDh_Def _Cot herm : Dat eDh_Def _Puissance : Dat eDh_Def _Pr of ilCoke : Dat eDh_Def PuissanceCale : Dat eDh_Def _Planif ee : Dat e

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

1

0. . *

PlaceO f M elange

( f r om Concept ualM odelPck)

0. . n0. . 1 0. . n0. . 1

SubM vt Char bon

Num er o : I nt egerPoids : LongDat eTim e : Dat e

0. . n

1

0. . n

1

Char bon

Number : I nt egerNom : St r ing

0. . n

1

0. . n

1 O r igen

Envoi

Num er o : I nt eger

0. . 1

0. . n

0. . 1

0. . n

0. . 1

0. . n

0. . 1

0. . n

0. . 1

0. . n

0. . 1

0. . n

PlaceO f Coke( f r om Concept ualM odelPck)

0. . n

0. . 1

0. . n

0. . 1

M elange

Num er o : I nte gerSwe llingI nd Con t M ax : Lon gSwe llingI nd DilM ax : L on gNom : S t rin g

SubM vt M elange

Numer o : I nt egerPoids : LongDat eTim e : Dat e

0. . n

1

0. . n

1

M vt Char bon

Numer o : I nt egerPoids : LongDat eTim e : Dat e

1

0. . n

1

0. . n

1

0. . n

1

0. . n

0. . 1

0.. 1

0. . 1

0.. 1 Ent r epr iseNom : St r ing

Coke

Num er o : I nt egerI RSI D_I 10 : LongI RSI D_I 20 : LongI RSI D_I 40 : LongNom : St r ing

SubMvt Coke

Num er o : I nt egerPoids : LongDat eTime : Dat e

0. . n

1

0. . n

1

Elem entNom : St r ing

0. . n

0. . n

0. . n

0. . n

M vt M elange

Numer o : I nt egerPodis : LongDat eTim e : Dat e

1

0. . n

1

0. . n

1

0. . n

1

0. . n

0. . n 0. . n0. . n 0. . n

0. . n

0. . n

0. . n

0. . n

M vt CokeNum er o : I nt egerPoids : LongDat eTime : Dat eRet our n : Boolean

0. . n

0. . n

0. . n

0. . n

1

0. . n

1

0. . n1

0. . n

1

0. . n

1 0. . 11 0. . 1

0. . n

0. . n

0. . n

0. . n

G ranulom et r ie

I nt er val : St r ingNom : St r ing

0. . n

0. . n

0. . n

0. . n

0. . n

0. . n

0. . n

0. . n

Com poseMelangeQ uant it e : I nt eger

FADS Reservelocalisation : String

mesuretempérature : Doubletemps : Date

matière_premièrepropriétéquantité : Integer

personnenom : Stringprénom : Stringâge : Integertitre : String

Equipe_de_travailrotation : Integernombre personne : Integercontremaître : personnehoraire : Date1..n 11..n 1

guide coke à mesure

Positionable

position()aligner()est_libre()aligné_sur()

enfourneuse-à-mesure

Chariot_RacleurLocalisation : string

transfert()stop_transfert()est_actif()

TransporteurLocalisation : String

est_actif()démarrer()arrêter()

Detecteur_Overband

detection_dechirure()arrêter()est_actif()

Bande_Transporteuse

démarrer()arrêter()est_actif()

1

1

1

1

0..10

1

0..10

1

1

1

1

1

Stock_CharbonType : StringProvenance : StringDate : Date

transfert()livraison()

0..11..n 0..11..n

transporte Silo_Magasincapacité

10..1 10..1

stocke

Brut

0..1

0..*

0..1

0..*

déplace0..1

1

0..1

1

Stocke

EQ.FADS

0..n

0..1

0..n

0..1

contrôle

0..1

0..n

0..1

0..n

EQ reglage

Silo_Doseurcapacité

1..n0..n

1..n0..n

melange

SiloNiveau : IntegerHumidite : DoubleLocalisation : StringCapacité : Integer

mélange()remplir_silo()

0..*0..*

0..*0..*

contient

0..1

0..*

0..1

0..*

CarneauNumero : IntegerTemperature : Integer

est_en_chauffe()

0..n

0..1

0..n

0..1

planning_e

Bande_Transporteuse_pate

1..10

0..1

1..10

0..1

transfère

EQ prep

0..2

0..10

0..2

0..10

dirige

0..2

0..n

0..2

0..n

controle

PiedroitNumero : Integersens_inversion : Boolean

inversion()check_pression()check_température()

1

1..n

1

1..n

compose

Broyeur

démarrer()arrêter()est_actif()

1

1..*

1

1..*

enfournementquantité : Doubledate et heure planifée : Datedate et heure effective : Date 1 1..*1 1..*

Tour_à_CharbonNiveau : Integer

transfert_charbon()approvisionnement()mélange()

0..1 0..10..1 0..1

transfere

0..1

0..2

0..1

0..2

s'occupe

BatterieNom : {Coppee1, Coppee2, Koppers, Didier}Temperature_globale : IntegerHeure_inversion_suivante : Datenb_fours : Integertemps cuisson : Integernb_carneau : Integerqté_enfournable : Integer

1..n

1

1..n

1EQ maçon

réparer-four()

Pâte_à_coke

0..1 0..n0..1 0..n

broie

0..1

0..n

0..1

0..n

Contient

coketempérature : Integer

criblé()

Planning_ddefournement_en_cours : Defournement

defournement_suivant()optimiser()

Coke_Carpuissance : Integeralimentation : Variant

est-vide()réceptionner_mp()aligner_tour()aligner_cribleur()aligner_aire()deverser_coke()

Tour_ExtinctionNiveau_eau : Integer

déverse_charge()est_libre()reservoir_plein() 0..1

0..2

0..1

0..2

éteint saumon

Enfourneusenom : Stringniveau : Integerpuissance : Integeralimentation : Variant

aligner_tour()remplir_four()ouvrir_enfourneuse()fermer_enfourneuse()ouvrir_bouches()fermer_bouches()

0..n0..1

0..n0..1

approvisionne

0..*

0..*

0..*

0..*

entre

Fournuméro : Integerrespecte_planning : BooleanTemperature : Integercapacité : Integer

porte_entrée_ouverte()porte_sortie_ouverte()est_vide()est_enfourné()est_égalisé()cuisson_terminée()trappe_ouverte()ouvrir()fermer()activer()désactiver()température_estimé()

0..50 10..50 1

0..n

0..1

0..n

0..1

répare

0..n

0..n

0..n

0..n

contient0..n

0..2

0..n

0..2

remplit

Défourneusenom : Stringpuissance : Integeralimentation : Variantplanning : Planning_ddéfournement : Defournement

ouvrir_four()défourner()fermer_four()cherche_defournement()validation_defournement()ouvrir_trappe()égaliser_contenu_four()fermer_trappe()

Criblage

cribler()arrêter()est_libre()

0..20..1

0..20..1

apporte coke

0..1

0..n

0..1

0..n

Aire_a_Coketemps_attente : Date

attente_refroisissement()arrosage()est_libre()

0..2

0..1

0..2

0..1

apporte saumon

0..1

0..n

0..1

0..n

Saumonprofil : profiltempérature (haut) : Integertempérature (milieu) : Integertempérature (bas) : Integer

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

Defournementdate & heure planifiées : Datedate & heure effectives : Dateforce : Force de défournementfour : Fourcoke_car : Coke carguide_coke : Guide cokedefourneuse : Défourneusecause_non_respect_timing : Stringpression : Integer

encoder_cause()

1

0..1

1

0..1

1

0..n

1

0..n

correspond

0..n

1

0..n

1

1

0..n

1

0..n

correspond

1

0..n

1

0..n

correspond

EQ four

0..2

0..4

0..2

0..4

0..1

0..4

0..1

0..4

0..n

0..4

0..n

0..4

dirige

0..4

0..n

0..4

0..n

contrôle

0..n

1

0..n

1

prépare

0..3

0..4

0..3

0..4

0..1

0..4

0..1

0..4

0..1

0..4

0..1

0..4

Auge_MobileEn_place : Boolean

Guide_Cokepuissance : Integeralimentation : Variant

transférer_saumon()ouvrir_porte()fermer_porte()prendre_t°()t°haut()t°milieu()t°bas()prendre_profil()

0..1

0..n

0..1

0..n

1

0..n

1

0..n

correspond

0..4

0..4

0..4

0..4

(F) Iteration 1 : Elaboration(F) Iteration 1 : Elaboration

Requirements Requirements

(G) Iteration 2 : Construction(G) Iteration 2 : Construction

AnalysisAnalysis

10 - 28

System Architect (Class System Architect (Class DiagDiag.).)

Locomotive

NumLoco : Long

GroupLoco

Numero : Long

1

1. .n

1

1. .nconduit

Tender

Tender : Long

0..1

0. .n

0..1

0. .naccompagne

PlaceProduct ion

Code : String

AnalyseCharbon

Quantite : Long

AnalyseMelange

Quant ite : Long

AnalyseCoke

Quantite : Long

Sales

Poids : LongDateTime : Date

RecapPauseCoProduit

DhPause : DateExt racteurNord : SingleExt racteurSud : SingleVitesseNord : SingleVitesseSud : SingleDebitNord : S ingl eDebitSud : Si ngleTemperatureVoluteNord : SingleTemperatureVoluteSud : SingleAmperageNord : S ingl eAmperageSud : Si ngleRegulationNord : St ri ngRegulationSud : S tringVanneRappoldNord : StringVanneRappoldSud : StringPressi onHuileEntreeNord : SinglePressi onHuileEntreeSud : SinglePressi onHuileSortieNord : SinglePressi onHuileSortieSud : SingleVibrationHorizontaleNord : SingleVibrationHorizontaleSud : SingleVibrationVerticaleNord : SingleVibrationVerticaleSud : SingleTemperatureExterieureNord : SingleTemperatureExterieureSud : SingleCondensationDebi t : SingleCondensationAnal yse : SingleLavageDebi t : SingleLavageAnal yse : SingleCSFDebit : SingleCSFAnalyse : SingleBiologiqueDebit : S ingleBiologuiqueAnalyse : SingleVenturiDebit : S ingl eVenturiTemperature : SingleVenturiPh : S ingl eBrigadier : StringOperateur : S tringOperateurGazom etre : StringI ti nerantCoproduit : StringI ti nerantBioGazometre : StringChaguerGourdon : StringHorsQuota : StringTempSortieCTH1 : S ingleTempSortieCTH2 : S ingleTempSortieCTH3 : S ingleTempSortieCTH4 : S ingleTempSortieEGR1 : SingleTempSortieEGR2 : SingleTempSortieEGR4 : SingleTempSortieEGR3 : SingleTempEntreeLaveur5Nord : SingleTempEntreeLaveur5Sud : SingleTempEntreeLaveur1Nord : SingleTempEntreeLaveur1Sud : SinglePressi onEtDebitVapeur : StringNiveauRes500 : Si ngleNiveauResB500 : SingleNiveauRes1000 : Si ngleNiveauRes800 : Si ngleNiveauRes6514 : Si nglePosteE met teur : StringDetecteurCO : StringCommentaire : StringSignatureBrigadier : S tringCommentaireOperateur : StringSignatureOperateurTechnique* : StringVolumeResFuel 6509 : SingleHauteurResFuel 6509 : SingleVolumeResFuel 6508 : SingleHauteurResFuel 6508 : SingleVolumeResFuel 6511A : SingleHauteurResFuel 6511A : SingleVolumeResFuel 6511B : SingleHauteurResFuel 6511B : SingleLaveur1NordDebit : SingleLaveur1NordPassage : SingleLaveur1SudDebit : SingleLaveur1SudPassage : SinglePerteFuel : SingleHauteurSoudeAvant : SingleHauteurSoudeApres : SingleConsommationSoude : Single

encoderCahierElect ronique()

MesureSynchroneBat terieM inute

Dh_M esure : DateV001 : IntegerV077 : Integer

MesureSynchroneDi versJour

Dh_Mesure : DateV001 : IntegerV065 : Integer

MesureSynchroneDiversMinute


MesureSynchroneDiversPause


RecapPauseFour

DhPause : DateNomAjusteur : StringCommentaireAjusteur : StringSignatureAjusteur : StringNomElectrician : StringCommentaireElectrician : StringSignatureElectrician : StringNomContremaitre : StringAssistantContremaitre : StringCommentaireContremaitre : StringSignatureContremaitre : StringNbreDefournementCoppee : SingleNbreDefournamentKoppers : SingleNbreDefournamentDidier : SingleEtatCuissonCoppee : StringEtatCuissonKoppers : StringEtatCuissonDidier : StringPlateauCoppeeNettoyeCoteCoke : StringPlateauKoppersNettoyeCoteCoke : StringPlateauDidierNettoyeCoteCoke : StringPlateauCoppeeNettoyeCoteMachine : StringPlateauKoppersNettoyeCoteMachine : StringPlateauDidierNettoyeCoteMachine : StringTpsExtinctionEnSeconde : IntegerTpsEgouttageEnSeconde : IntegerTpsExpeditionCK16EnMinute : IntegerPompeEnService : StringCokecarEnService : String

RecapJourCoProduit

DhJour : Dat eVol umeRes2Goudron : IntegerVol umeRes3Goudron : IntegerVol umeRes4Goudron : IntegerVol umeRes5Goudron : IntegerVol umeRes6Goudron : IntegerVol umeRes7Goudron : IntegerVol umeRes8Goudron : IntegerVol umeRes9Goudron : IntegerVol umeRes10Goudron : IntegerCpteurFuel VersCent ral Avant : IntegerCpteurFuel VersCent ral Apres : IntegerLitrageFuelVersCentral : Integer

CamionCoProduit

NoPlaque : String0..* 0..*0..* 0..*

Deplacer

Dh_DepartG oud : DateRetourEauCami on : Bool eanType : StringFi rm eEntreeFuel : StringHteurAvantEntreeFuel : Si ngleHteurApresEntreeFuel : SingleNoResEnt reeFuel : SingleLi trageEntreeFuel : SingleHeureEntree : S tring

Place

Name : String0. .n1 0. .n1

concerne

Test2 : String

Livere

Test2 : String

Participer

Test : String

Defournem ent_Cotherm

V001 : IntegerV177 : Integer

enregistrementTemperatureCotherm()carteCothermBatterie()carteCothermFour()moyenneTempCotherm()ecartTypeTempCotherm()courbesTemperatureSaumon()historiqueCourbesTemperatureSaumon()checkCarneaux()

Defournament_Puissance


enregistrementPuissance()cartePuissanceBatterie()cartePuissanceFour()evolution3DPic()evolution3DPAD()evolution3DID()evolutionPuissanceMoyenneBatterie()picMoyDerniersDefournements()nbrFoursCaleMoisPuissanceMois()

Defournement_Profi lCoke


enregistrementProfilCoke()encoderCahierElectronique()

GranCoke

Quantite : Integer

GranMelange

Quantite : Integer

Bassin

Bassin : LongLibelle : String

Site

Site : LongLibelle : String

0..n

1

0..n

1

MsgGroupe

Id_GroupMsg : IntegerLibelleMsg : StringTypeMsg : String

Usine

Usine : Long

0..n

1

0..n

1

TCxSerieTempPyrometre

NumCx : IntegerTemperature : Integer

enregistrerTempCx()getTempSerie()

TcxTypeDeMesure

Id_TypeDeMesure : IntegerLibelle : String

MsgCommunication

Auteur : StringDh_DebutAf fichage : DateDh_FinAffichage : DateCommentaire : StringResponse : String

1

0..*

1

0..*

1

0..*

1

0..*

Service

Service : LongLibelle : String

0..n

1

0..n

1

TCxListeSerieTempPyrometre

Id_Serie : IntegerTypeDeGaz : StringPCI : IntegerDh : DatePyrometreur : StringRegleur : StringCommentaire : StringValide : Boolean

encoderSerieTempCx()validerSerie()encoderCommentaire()historiqueTCx5-22()

1

0. .*

1

0. .*

1

0..*

1

0..*

MessageRejete

Id_Msg : IntegerDateTraitementMsg : DateNumeroErreur : IntegerDescriptionErreur : StringEmetteurMsg : StringNumeroMsg : IntegerLibelleMsg : StringSourceErreur : String

10..1 10..1

PDefParametre

Id : IntegerDateDerniereModif : DateCommentaire : StringDh_PauseEnCours : DateTpsCuissonCoppee : IntegerTpsCuissonKoppers : IntegerDelaiEntreDefournEtEnfourn : IntegerEcartMaxTpsCuissonCoppee : IntegerEcartMaxTpsCuissonKoppers : IntegerEcartSurProgrTolereCoppee : IntegerEcartSurProgrTolereKoppers : IntegerDefaultDelaiEntreDefEtEnf : IntegerModifDhMachineAutorisee : IntegerDelaiEnSecondeDuRefreshAutoInterface : IntegerTimeOutExecuteModele : IntegerNbrHeureAvantPauseCouranteAVisualiser : IntegerNbrHeureApresPauseCouranteAVisualiser : IntegerPasswordOption : StringAnimationVideo : IntegerM_PV_Enabled : IntegerM_PV_kdpapHS : IntegerEntretienHeureMin : IntegerEntretienHeureMax : IntegerEntretienDureeMin : IntegerEntretienDureeMax : IntegerEntretienPasMin : Integer

PlanningEntretien

Dh_Debut : DateDureeEnMi nute : Integer

ConsigneTempsCuisson

Id_Consigne : IntegerDh_DebutChangement : DateConsTpsCuis_KoppersDidier : IntegerConsTpsCuis_Coppee : Integer

PdelListeHeurePourModeleLight

Id_Progr : IntegerHeureFour : Date

PdefDHPourDebug

DhMaintenant : DateDhAvant : Date

Personne

Id_Personne : IntegerPrenom : StringNom : StringDateNaissance : Date

PdefNombreFourProduit

Dh_Pause : DateNbreFourCopModelise : IntegerNbreFourKDModelise : IntegerNbreFourCopProgramme : IntegerNbreFourKDProgramme : IntegerNbreFourCopRealise : IntegerNbreFourKDRealise : Integer

PdefEtat

Etat : IntegerLibelle : StringSignification : String

tiers

cod_tie : Integernom_tie : Stringadr_tie : Stringori : String

getCod_tie()

Transporteur

interdit : String

checkInterdictionTransporteur()interdireTransporteur()

Fam_article

fam_art : Stringlib_fam : Stringori : String

Post

pst_num : Integerdat_pst : Date

Fournisseur(from ConceptualModelPck)

Client(from ConceptualModelPck)

Bascule

bas_id : Integerbas : String

Badge

num_bad : Integerdat_cre : Datedat_mod : Datetyp_bad : Stringnum_pas : Integerpas_max : Integercod_ina : Booleanver_com : Stringrec_bad : Stringrem : Stringrem_com : Stringvalide : Booleander_pes : Stringbad_act : Boolean

expireBadge()getBadgeDisponible()l ibererBadge()getValiditeBadge()

Voie

Voie : StringIndexVoie : LongType : StringLibelle : StringOrientation : StringSensPriv : StringEtat : StringLoungueur : LongCulDeSac : Boolean

0..n1 0..n1

dans

EtatWagon

Etat : StringLibelle : String

TypeWagon

TypeWagon : StringLibelle : StringCouleur : String

CategChomage

CategChomage : StringLibelle : String

tempsChomageMax()

TypeMatiere

TypeM ati ere : Str ingLi bell e : St ri ngCoul eur : String

Pi edroi t

Id_Pdt : IntegerLibelle : String

1

0..*

1

0..*

M essageTraceChronol ogiqueData

DateTraitementMsg : DateEmetteurMsg : DateNumeroMsg : DateNumeroSec : DateDh_Data : DateEnteteMsg : StringDh_Pause : DateDh_Jour : DateDh_Mois : Date

1 0..*1 0..*

Bat terie

Id_Batterie : IntegerLibelle : StringId_PdtDebut : IntegerNom : St ri ngNumFourDeb : IntegerNbrFour : IntegerNbrPdt : String

1

0..*

1

0..*

0..1

0..*

0..1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1 0..*1 0..*

1

0..*

1

0..*

PlanningPoste

Id_Cycle : IntegerEquipe : Integer 10..* 10..*

PdefListeResult

Id_Resul tat : IntegerDh_IdResultat : DateDh_Pause : DateTypeDeModele : StringNomMachineCli ent : Str ingNomUser : StringStatusExecuti onModel e : IntegerDh_FinExecuteModele : DateLibelleStatus_Fi nExecuteM odele : StringCommentaireResultat : String

startModelePV()startModeleLi ght()setResultat()imprimePlanni ng()

1 0..*1 0..*

10..*

10..*

PdefResultat

Dh_Def_Prevue : DateEtat_Prevu : IntegerEtat_HS_Prevu : IntegerDh_Def_PrevueCorrigee : DateEtat_Corrige : IntegerEtat_HS_Corrige : IntegerEntretien : StringCommentaire : StringDh_Enf_Prec : DateDh_Def_Minimale : DateOperation : String

enregistrePlanningPropose()enregistrePlaningValide()

1

0..*

1

0..*

Enfournement_Divers

V001 : IntegerV100 : IntegerDh_Pause : DateDh_Jour : DateDh_Mois : Date

Localite

cod_loc : Stringloc : String

1

0..*

1

0..*

Camion

pla_cam : Stringchg_max : Integertare : Integerfrc_tar : Integerdat_tar : Dateder_tar : Date

assignerBadge()

10..1 10..1

11..*11..*

Article

cod_art : Integercod_env : Stringl ib_art : Stringl ibel le : Stringori : String

1

1..*

1

1..*1

0..*

1

0..*

Commande

num_com : Integerent_srt : Boolean

getCommande()

1 1..*1 1..*

1 0..*1 0..*

10..*

10..*

Pesee

num : IntegerDateTime : Datepesee1 : Integerpesee2 : Integerpes_val : Booleanpes_ann : Booleanrem : Stringrem_sys : Stringstatus : Stringlib_pre : Stringcod_pre : Integer

encoderPesee()supprimerPesee()

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

EnteteMvt

NumMvt : LongTypeMvt : S tringIntercal er : StringInversion : StringTypeMvtSens : St ri ngDateEnreg : DateDateDebut : DateDateFin : DateVoieDespose : StringSensDepose : St ri ng

inverserConvoi()effectuerMvt()

Raccordement

RaccSncb : StringLibelle : StringRaccCklSam : Boolean

1..n

1

1..n

1

Wagon

NumWagon : LongPoidsBrut : LongTare : LongPoidsNet : LongPoidsTheorique : LongLongueur : LongDateTimeDebChomage : DateNumChassis : Integer

setDebutChomage()setFinChomage()calculerTempsChomage()

0..n

1

0..n

1

de type 2

0..n 10..n 1

de type

0..n0..1

0..n0..1

Matiere

Matiere : StringLibelle : String 0. .n

10. .n

1

de type 1

Defourneuse

Id_Defourneuse : IntegerLibDefourneuse : StringId_Engin : IntegerPuissanceMaximale : IntegerPuissanceCalculPad : IntegerPuissanceCalculTGr : IntegerCoefCorrMul : IntegerCoefCorrAdd : IntegerNbrSecondeEchanti llonnage : IntegerTpsMaxDefournament : IntegerSurfaceRef : Integer

Four

Id_Four : Integer1

1..2

1

1..2

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

PlanningDefournement

Dh_Def_Planifiee : DateDh_Def_Validee : DateDh_Enf_Validee : DateDh_Def_Mach : DateDh_Enf_Mach : DateDh_Enf_Prec : DateEtat : IntegerEtat_Prec : IntegerEtat_HS : IntegerEtat_RP : IntegerDh_Def_Corrigee : DateDh_Enf_Corrigee : DateJustificatif : IntegerCommentaire : StringEntretien : StringFlag_Dh_Def_Mach_MajAPRESCCorrection : IntegerFlag_Dh_Enf_MachAPRESCorrection : Integer

validationEnfournement()validationDefournement()setPlanning()

0..*

0..*

0..*

0..*

1

0..1

1

0..1

1

0..*

1

0..*10..1

10..1

Enfournement

Dh_Enf : DateDh_Enf_Divers : Date

enfournementE3()enfournementE1()txUti l isationE3()

1

0..1

1

0..1

1

0..*

1

0..*

1

0..*

1

0..*

Pl aceOfCharbon(from ConceptualModelPck)

Pays

cod_pay : Integerpay : String

0..n

1

0..n

1

1

0..*

1

0..*

Bateaux

Nom : String

Livraison

cod_liv : Integerl ib_liv : Stringori : String 0..*0..* 0..*0..*

0..*

0..*

0..*

0..*

10..1 10..1

MvtDetail

DateTim e : DatePosit ion : IntegerNum LVoit : IntegerPoi dsNet : LongPoi dsBrut : LongPoi dsT heori que : LongTare : LongStatut : St ri ng

creerConvoi()di ssoudreConvoi ()getPosi ti on()setPosi ti on()

1

0..n

1

0..n

1 0. .n1 0. .n

1

0..n

1

0..n

10..n

10..n Defournement

Dh_Def : DateDh_Def_Cotherm : DateDh_Def_Puissance : DateDh_Def_Profi lCoke : DateDh_DefPuissanceCale : DateDh_Def_Planifee : Date1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

Pl aceOfMelange( from Conceptual ModelPc k)

0..n0..1 0..n0..1

SubM vtCharbon

Numero : IntegerPoids : LongDateTime : Date

0..n

1

0..n

1

Charbon

Number : IntegerNom : String

0..n

1

0..n

1 Origen

Envoi

Numero : Integer

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

0..1

0..n

PlaceOfCoke(from Conceptual ModelPck)

0. .n

0. .1

0. .n

0. .1

Melange

Num ero : IntegerSwel li ngIndContM ax : LongSwel li ngIndDil Max : LongNom : St ri ng

SubMvtM elange


0..n

1

0..n

1

MvtCharbon


1

0. .n

1

0. .n

1

0. .n

1

0. .n

0..1

0..1

0..1

0..1 Entreprise

Nom : String

Coke

Numero : IntegerIRSID_I10 : LongIRSID_I20 : LongIRSID_I40 : LongNom : String

SubMvtCoke


0..n

1

0..n

1

Element

Nom : String

0..n

0..n

0..n

0..n

MvtMelange

Numero : IntegerPodis : LongDateTim e : Date

1 0..n1 0..n

1

0..n

1

0..n

0..n 0..n0..n 0..n

0. .n

0..n

0. .n

0..n

M vtCoke

Numero : IntegerPoids : LongDateTime : DateRetourn : Boolean

0..n

0..n

0..n

0..n

1

0..n

1

0..n1

0..n

1

0..n

1 0..11 0..1

0..n

0..n

0..n

0..n

Granulometrie

Interval : StringNom : String

0..n

0. .n

0..n

0. .n

0..n

0..n

0..n

0..n

ComposeMelange

Quantite : Integer

(H) Iteration 3 : Construction(H) Iteration 3 : Construction

Design Design

10 - 29

System Architect (Class System Architect (Class DiagDiag.).)

(I) (I) ItItéérationration 4 : Construction4 : Construction

Implementation Implementation

Defournement_Cotherm

Dh_Def : DATETIMEId_Four : INTV001 : INTV177 : INT

Defournament_Puissance


Defournement_ProfilCoke


MesureSynchroneBatterieMinute

Dh_Mesure : DATETIMEV001 : INTV077 : INT

MesureSynchroneDiversJour


MesureSynchroneDiversMinute

Dh_Mesure : DATETIM EV001 : INTV106 : INT

MesureSynchroneDiversPause


RecapPauseCoProduit

DhPause : DATETIMEExtracteurNord : FLOAT(32, 0)ExtracteurSud : FLOAT(32, 0)VitesseNord : FLOAT(32, 0)VitesseSud : FLOAT(32, 0)DebitNord : FLOAT(32, 0)DebitSud : FLOAT(32, 0)TemperatureVoluteNord : FLOAT(32, 0)TemperatureVoluteSud : FLOAT(32, 0)AmperageN ord : FLOAT(32, 0)AmperageSud : FLOAT(32, 0)RegulationNord : VARCHAR(255)RegulationSud : VARCHAR(255)VanneRappoldNord : VARCHAR(255)VanneRappoldSud : VARCHAR(255)PressionH uileEntreeNord : FLOAT(32, 0)PressionH uileEntreeSud : FLOAT(32, 0)PressionH uileSor tieNord : FLOAT(32, 0)PressionH uileSor tieSud : FLOAT(32, 0)VibrationH orizontaleNord : FLOAT(32, 0)VibrationH orizontaleSud : FLOAT(32, 0)VibrationVerticaleNord : FLOAT(32, 0)VibrationVerticaleSud : FLOAT(32, 0)TemperatureExter ieureNord : FLOAT(32, 0)TemperatureExter ieureSud : FLOAT(32, 0)Condensat ionDebit : FLOAT(32, 0)Condensat ionAnalyse : FLOAT (32, 0)LavageDebit : FLOAT(32, 0)LavageAnalyse : FLOAT(32, 0)CSFDebit : FLOAT(32, 0)CSFAnalyse : FLOAT(32, 0)BiologiqueDebit : FLOAT(32, 0)BiologuiqueAnalyse : FLOAT(32, 0)VenturiDebit : FLOAT(32, 0)VenturiTemperature : FLOAT(32, 0)VenturiPh : FLOAT(32, 0)Brigadier : VARCHAR(255)Oper ateur : VARCHAR(255)Oper ateurGazometre : VARCHAR(255)Itiner antCoproduit : VARCHAR( 255)Itiner antBioGazometre : VARC HAR(255)ChaguerGourdon : VARCHAR(255)HorsQuota : VARCHAR(255)TempSortieCTH1 : FLOAT(32, 0)TempSortieCTH2 : FLOAT(32, 0)TempSortieCTH3 : FLOAT(32, 0)TempSortieCTH4 : FLOAT(32, 0)TempSortieEGR1 : FLOAT(32, 0)TempSortieEGR2 : FLOAT(32, 0)TempSortieEGR4 : FLOAT(32, 0)TempSortieEGR3 : FLOAT(32, 0)TempEntreeLaveur5Nord : FLOAT(32, 0)TempEntreeLaveur5Sud : FLOAT(32, 0)TempEntreeLaveur1Nord : FLOAT(32, 0)TempEntreeLaveur1Sud : FLOAT(32, 0)PressionEtDebitVapeur : VARCHAR( 255)NiveauRes500 : FLOAT(32, 0)NiveauResB500 : FLOAT(32, 0)NiveauRes1000 : FLOAT(32, 0)NiveauRes800 : FLOAT(32, 0)NiveauRes6514 : FLOAT(32, 0)PosteEmet teur : VARCHAR(255)DetecteurCO : VARCHAR(255)Commentair e : VARCHAR(255)Sig natureBr igadier : VARCHAR(255)Commentair eOperateur : VARCHAR( 255)Sig natureOperateurTechnique : VARCHAR( 255)VolumeResFuel6509 : FLOAT(32, 0)HauteurResFuel6509 : FLOAT (32, 0)VolumeResFuel6508 : FLOAT(32, 0)HauteurResFuel6508 : FLOAT (32, 0)VolumeResFuel6511A : FLOAT(32, 0)HauteurResFuel6511A : FLOAT(32, 0)VolumeResFuel6511B : FLOAT(32, 0)HauteurResFuel6511B : FLOAT(32, 0)Laveur1NordDebit : FLOAT(32, 0)Laveur1NordPassage : FLOAT(32, 0)Laveur1SudDebi t : FLOAT(32, 0)Laveur1SudPassage : FLOAT( 32, 0)Per teFuel : FLOAT(32, 0)HauteurSoudeAvant : FLOAT(32, 0)HauteurSoudeApr es : FLOAT(32, 0)ConsommationSoude : FLOAT(32, 0)

Place

Name : VARCHAR(255)

CamionCoProduit

NoPlaque : VARCHAR(255)

RecapJourCoProduit

DhJour : DATETIM EVolumeRes2Goudron : INTVolumeRes3Goudron : INTVolumeRes4Goudron : INTVolumeRes5Goudron : INTVolumeRes6Goudron : INTVolumeRes7Goudron : INTVolumeRes8Goudron : INTVolumeRes9Goudron : INTVolumeRes10Goudron : INTCpteurFuelVersCentral Avant : INTCpteurFuelVersCentral Apr es : INTLit rageFuelVersCentral : IN T

Deplacer

Dh_DepartGoud : DATETIMERetourEauCamion : BITType : VARCHAR(255)FirmeEntreeFuel : VARCHAR(255)HteurAvantEntreeFuel : FLOAT(32, 0)HteurApresEntreeFuel : FLOAT(32, 0)NoResEntreeFuel : FLOAT(32, 0)LitrageEntreeFuel : FLOAT(32, 0)HeureEntree : VARCHAR(255)Name : VARCHAR(255)NoPlaque : VARCHAR(255)DhJour : DATETIME

1 0..*1 0..*

<<Non-Identifying>>

1

0..*

1

0.. *

<<Identifying>>

10..* 10..*

<<Identifying>>

RecapPauseFour

DhPause : DATETIMENomAj usteur : VARCHAR(255)CommentaireAjusteur : VARCHAR (255)Sig natureAjusteur : VARCHAR( 255)NomEl ectrician : VARC HAR( 255)CommentaireElectr ic ian : VAR CHAR(255)Sig natureElectri cian : VARCH AR(255)NomC ontremai tr e : VARCH AR( 255)AssistantContremai tr e : VARC HAR( 255)CommentaireContremai tr e : VARCH AR( 255)Sig natureContremaitre : VAR CHAR (255)Nbr eDefournementCoppee : FLOAT( 32, 0)Nbr eDefournamentKoppers : F LOAT(32, 0)Nbr eDefournamentD idier : FLOAT( 32, 0)EtatCuissonCoppee : VARCHAR(255)EtatCuissonKopper s : VARCH AR(255)EtatCuissonDidi er : VARCHAR(255)PlateauCoppeeNettoyeCoteCoke : VARC HAR( 255)PlateauKoppersNettoyeCoteCoke : VARCHAR(255)PlateauDidier NettoyeCoteCoke : VARC HAR( 255)PlateauCoppeeNettoyeCoteM achi ne : VARCHAR(255)PlateauKoppersNettoyeCoteMachine : VARCHAR(255)PlateauDidier NettoyeCoteM achi ne : VARCHAR(255)TpsExt inc ti onEnSeconde : INTTpsEgouttageEnSeconde : INTTpsExpedit ionCK16EnMinute : INTPompeEnService : VARCHAR(255)Cokecar EnService : VARCHAR(255)

Bassin

Bassin : BIGINTLibelle : VARCHAR(255)

MsgGroupe

Id_GroupMsg : INTLibelleMsg : VARCHAR(255)TypeMsg : VARCHAR(255)

Site

Site : BIGINTLibelle : VARCHAR(255)Bassin : BIGINT

1

0..*

1

0..*

<<Identifying>>

Usine

Usine : BIGINTBassin : BIGINTSite : BIGINT

1

0..*

1

0..*

<<Identifying>>

Personne

Id_Personne : INTPrenom : VARCHAR(255)Nom : VARCHAR(255)DateNaissance : DATETIME

MsgCommunication

Id_Msg : INTAuteur : VARCHAR(255)Dh_DebutAffichage : DATETIMEDh_FinAffichage : DATETIMECommentaire : VARCHAR(255)Response : VARCHAR(255)Id_GroupMsgOri : INTId_GroupMsgDst : INT

10..* 10..*

<<Non-Identifying>>

10..* 10..*

<<Non- Identifyi ng>>


NumCx : INTTemperature : INTId_Ser ie : INT

TcxTypeDeMesure

Id_TypeDeMesure : INTLibelle : VARCHAR(255)

Fam_article

fam_ar t : VARCHAR (255)li b_fam : VAR CHAR(255)ori : VARC HAR(255)

Post

pst_num : INTdat_pst : DATETIMEcod_art : INTnum_com : INT

Service

Service : BIGINTLibelle : VARCHAR(255)Bassin : BIGINTSite : BIGINTUsine : BIGINT

1

0..*

1

0..*

<<Identifying>>

Locomotive

NumLoco : BIGINTNumero : BIGINTNumWagon : BIGINT

Tender

Tender : BIGINTNumero : BIGINTNumWagon : BIGINT

Client

cod_tie : INT

Fournisseur

cod_tie : INT

PdefEtat

Etat : INTLibelle : VARCHAR(255)Signification : VARCHAR(255)

PdefNombreFourProduit

Dh_Pause : DATETIMENbreFourCopModelise : INTNbreFourKDModelise : INTNbreFourCopProgramme : INTNbreFourKDProgramme : INTNbreFourCopRealise : INTNbreFourKDRealise : INTId_Resultat : INT

PlanningPoste

Id_Cycle : INTEquipe : INTId_Personne : INT

1 0..*1 0..*

<<Non-Identifying>>

MessageRejete

Id_Msg : INTDateTraitementMsg : DATETIMENumeroErreur : INTDescriptionErreur : VARCHAR(255)EmetteurMsg : VARCHAR(255)NumeroMsg : INTLibelleMsg : VARCHAR(255)SourceErreur : VARCHAR(255)

1

0..1

1

0..1

<<Identifying>>

TCxListeSerieTempPyrometre

Id_Serie : INTTypeDeGaz : VARCHAR(255)PCI : INTDh : DATETIMEPyrometreur : VARCHAR(255)Regleur : VARCHAR(255)Commentaire : VARCHAR(255)Valide : BITId_TypeDeMesure : INTId_Pdt : INT

1

0..*

1

0..*

<<Identi fying>>

1

0..*

1

0.. *

<<Non-Identifying>>

PdefDHPourDebug

DhMaintenant : DATETIMEDhAvant : DATETIMEId_Batterie : INT

PdelListeHeurePourModeleLight

Id_Progr : INTHeureFour : DATETIMEId_Batterie : INT

PlanningEntreti en

Dh_Debut : DATETIMEDureeEnMinute : INTId_Batterie : INT

ConsigneTempsCuisson

Id_Consigne : INTDh_DebutChangement : DATETIMEConsTpsCuis_KoppersDidier : INTConsTpsCuis_Coppee : INTId_Batterie : INT

PDefParametre

Id : INTDateDerniereModif : DATETIMECommentaire : VARCHAR(255)Dh_PauseEnCours : DATETIMETpsCuissonCoppee : INTTpsCuissonKoppers : INTDelaiEntreDefournEtEnfourn : INTEcartMaxTpsCuissonCoppee : INTEcartMaxTpsCuissonKoppers : INTEcartSurProgrTolereCoppee : INTEcartSurProgrTolereKoppers : INTDefaultDelaiEntreDefEtEnf : INTModifDhMachineAutorisee : INTDelaiEnSecondeDuRefreshAutoInterface : INTTimeOutExecuteModele : INTNbrHeureAvantPauseCouranteAVisualiser : INTNbrHeureApresPauseCouranteAVisualiser : INTPasswordOption : VARCHAR(255)AnimationVideo : INTM_PV_Enabled : INTM_PV_kdpapHS : INTEntretienHeureMin : INTEntretienHeureMax : INTEntretienDureeMin : INTEntretienDureeMax : INTEntretienPasMin : INTId_Batterie : INT

Article

cod_ar t : INTcod_env : VARCHAR(255)li b_art : VARCHAR(255)li belle : VARCHAR(255)ori : VARCHAR(255)fam_ar t : VARCHAR(255)

1

1..*

1

1..*<<Non-Identifying>>

1

0..*

1

0..*


Commande

num_com : INTent_srt : BITcod_tie_Clt : INTCod_tie_Fou : INT

1 1..*1 1..*

<<Non- Identifying>>

1 0..*1 0..*


1

0..*

1

0..*

<<Non-Identifying>>

Bascule

bas_id : INTbas : VARCHAR(255)

Voie

Voie : VARCHAR(255)IndexVoie : BIGINTType : VARCHAR(255)Libelle : VARCHAR(255)Orientation : VARCHAR(255)SensPriv : VARCHAR(255)Etat : VARCHAR(255)Loungueur : BIGINTCulDeSac : BITService : BIGINTBassin : BIGINTSite : BIGINTUsine : BIGINT

1 0..*1 0..*

<<Identifying>>

TypeMatiere

TypeMatiere : VARCHAR(255)Libelle : VARCHAR(255)Couleur : VARC HAR(255)

GroupLoco

Numero : BIGINTNumWagon : BIGINT

1

1..*

1

1..*

<<Identifying>>

0..1

0..*

0..1

0..*

<<Identifying>>

EtatWagon

Etat : VARCHAR(255)Libelle : VARCHAR(255)

TypeWagon

TypeWagon : VARCHAR(255)Libelle : VARCHAR(255)Couleur : VARCHAR(255)

CategC homage

CategChomage : VARCHAR(255)Libelle : VARCHAR(255)

Transporteur

interdit : VARCHAR(255)pla_cam : VARCHAR(255)cod_tie : INT

Badge

num_bad : INTdat_cre : DATETIMEdat_mod : DATETIMEtyp_bad : VARCHAR(255)num_pas : INTpas_max : INTcod_ina : BITver_com : VARCHAR(255)rec_bad : VARCHAR(255)rem : VARCHAR(255)rem_com : VARCHAR(255)valide : BITder_pes : VARCHAR(255)bad_act : BIT

tiers

cod_tie : INTnom_tie : VARCHAR(255)adr_tie : VARCHAR(255)ori : VARCHAR(255)cod_loc : VARCHAR(255)

1

0..1

1

0..1<<Identi fying>>

10..1

10..1

<<Identifying>>

1

0..1

1

0..1

<<Identifying>>

PdefListeResult

Id_Resultat : INTDh_IdResultat : DATETIMEDh_Pause : DATETIMETypeDeModele : VARCHAR(255)NomMachineClient : VARCHAR(255)NomUser : VARCHAR(255)StatusExecutionModele : INTDh_FinExecuteModele : DATETIMELibelleStatus_FinExecuteModele : VARCHAR(255)CommentaireResultat : VARCHAR(255)Dh_Def_Planifiee : DATETIMEEtat : INT

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

Participer

Id_Cycle : INTDh_Def_Planifiee : DATETIME

1

0..*

1

0..*

<<Identifying>>

MessageTraceChronologiqueData

DateTraitementMsg : DATETIMEEmetteurMs g : DATETIMENumeroMsg : D ATETIM ENumeroSec : DATETIMEDh_Data : DATETIMEEnteteMsg : VARC HAR(255)Dh_Pause : DATETIMEDh_Jour : D ATETIM EDh_Mois : DATETIMEId_Msg : INTId_Four : INT

1

0..*

1

0..*

<<Identifying>>

PdefResultat

Id_Resultat : INTId_Resultat : INTDh_Def_Prevue : DATETIM EEtat_Prevu : INTEtat_HS_Prevu : INTDh_Def_PrevueCorrigee : DATETIMEEtat_Corrige : INTEtat_HS_Corrig e : INTEntreti en : VARCHAR(255)Commentair e : VARCHAR(255)Dh_Enf_Prec : DATETIMEDh_Def_Minimale : DATETIMEOper ation : VARCHAR(255)Id_Four : INT

1

0..*

1

0..*

<<Identifying>>

Piedr oit

Id_Pdt : INTLibelle : VARCHAR(255)Id_Four : INTId_Batterie : INT

1

0..*

1

0..*

<<Non-Identifying>>

Batterie

Id_Batterie : INTLibelle : VARCHAR(255)Id_PdtDebut : INTNom : VARCHAR(255)NumFourDeb : INTNbrFour : INTNbrPdt : VARCHAR(255)

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

10..*

10.. *

<<Non-Identifyi ng>>

1

0..*

1

0..*

<<Non-Identifying>>

0..1

0..*

0..1

0..*

<<Non-Identifying>>

Defourneuse

Id_Defourneuse : INTLibDefourneuse : VARCHAR(255)Id_Engin : INTPuissanceM axi male : INTPuissanceC alculPad : INTPuissanceC alculTGr : INTCoefC orr Mul : INTCoefC orr Add : INTNbr SecondeEchantill onnage : INTTpsMaxDefournament : INTSurfaceR ef : INT

Livere

cod_l iv : IN Tcod_ar t : INT 10..* 10..*

<<Identifying>>

concer ne

num_com : INTcod_liv : INT

1

0..*

1

0..*

<<Identifying>>

Pesee

num : INTDateTime : DATETIMEpesee1 : INTpesee2 : INTpes_val : BITpes_ann : BITrem : VARCHAR(255)rem_sys : VARCHAR(255)status : VARCHAR(255)lib_pre : VARCHAR(255)cod_pre : INTnum_bad : INTbas_id : INTpla_cam : VARCHAR(255)cod_liv : INT

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

Raccordement

RaccSncb : VARCHAR(255)Libelle : VARCHAR(255)RaccCklSam : BITBassin : BIGINTSite : BIGINTUsine : BIGINTService : BIGINTVoie : VARCHAR(255)

1

1..*

1

1..*

<<Identifying>>

EnteteMvt

NumMvt : BIGINTTypeMvt : VARCHAR(255)Intercaler : VARCHAR(255)Inversion : VARCHAR(255)TypeMvtSens : VARCHAR(255)DateEnreg : DATETIMEDateDebut : DATETIMEDateFin : DATETIMEVoieDespose : VARCHAR(255)SensDepose : VARCHAR(255)

Matiere

Matiere : VARCHAR(255)Libelle : VARCHAR(255)TypeMatiere : VARCHAR(255)

10..* 10..*

<<Non-Identifying>>

Wagon

NumWagon : BIGINTPoidsBrut : BIGINTTare : BIGINTPoidsNet : BIGINTPoidsTheorique : BIGINTLongueur : BIGINTDateTimeDebChomage : DATETIMENumChassis : INTEtat : VARCHAR(255)TypeWagon : VARCHAR(255)CategChomage : VARCHAR(255)

1

0..*

1

0..*

<<Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

10..* 10..*


0..1

0..*

0..1

0..*

<<Non-Identifying>>

Cami on

pla_cam : VARCHAR(255)chg_max : INTtare : INTfrc_tar : INTdat_tar : DATETIMEder_tar : DATETIMEnum_bad : INTcod_pay : INT

1

1..*

1

1..*

<<Non-Identifying>>

10..1 10..1


1

0..*

1

0..*

<<Non-Identifying>>

Localite

cod_loc : VARCHAR(255)loc : VARCHAR(255)cod_pay : INT

1

0..*

1

0.. *

<<Non-Identifying>>

Enfournement_D ivers

V001 : INTV100 : INTDh_Pause : DATETIMEDh_Jour : DATETIMEDh_Mois : DATETIMEDh_Enf : DATETIME


Dh_Def_Planifiee : DATETIMEDh_Def_Validee : DATETIMEDh_Enf_Validee : DATETIMEDh_Def_Mach : DATETIMEDh_Enf_Mach : DATETIMEDh_Enf_Prec : DATETIMEEtat : INTEtat_Prec : INTEtat_HS : INTEtat_RP : INTDh_Def_Corrigee : DATETIMEDh_Enf_Corrigee : DATETIMEJustificatif : INTCommentaire : VARCHAR(255)Entretien : VARCHAR(255)Flag_Dh_Def_Mach_MajAPRESCCorrection : INTFlag_Dh_Enf_MachAPRESCorrection : INTId_Resultat : INTDh_Def_Prevue : DATETIMEId_Four : INT

0..11..* 0..11..*

<<Non-Identifying>>

1

0..1

1

0..1


1

0..*

1

0..*

<<Identifying>>

Four

Id_Four : INTId_Batterie : INT

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*


1

0..*

1

0..*

<<Non-Identifying>>

1

1..2

1

1..2

<<Non-Identifying>>

1

0..*

1

0..*<<Non-Identifying>>

Defournement

Id_Four : INTDh_Def : DATETIMEId_Four : INTDh_Def_Cotherm : DATETIMEDh_Def_Puissance : DATETIMEDh_Def_ProfilCoke : DATETIMEDh_DefPuissanceCale : DATETIMEDh_Def_Planifee : DATETIMEDh_Def_Planifiee : DATETIMECode : VARCHAR(255)Id_Defourneuse : INT

1 0..*1 0..*

<<Non-Identifying>>

10..* 10..*


0..*

1

0..*

1

<<Identifying>>

Livraison

cod_liv : INTlib_liv : VARCHAR(255)ori : VARCHAR(255)Numero : FLOAT(53, 0)

1 0..*1 0..*

<<Identifying>>

1

0..*

1

0..*

<<Identi fying>>

10..1 10..1

<<Non-Identifying>>

Bateaux

Nom : VARCHAR(255)MvtDetail

NumWagon : BIGINTNumMvt : BIGINTDateTime : DATETIMEPosition : INTNumLVoit : INTPoidsNet : BIGINTPoidsBrut : BIGINTPoidsTheorique : BIGINTTare : BIGINTStatut : VARCHAR(255)Numero : FLOAT(53, 0)Matiere : VARCHAR(255)RaccSncb : VARCHAR(255)Bassin : BIGINTSite : BIGINTUsine : BIGINTService : BIGINTVoie : VARCHAR(255)

1 0..*1 0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Identifying>>

10..* 10..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Identifying>>

PlaceOfCharbon

Code : VARCHAR(255)

Pays

cod_pay : INTpay : VARCHAR(255)

1

0..*

1

0..*

<<Non-Identifying>>

0..*

1

0..*

1<<Non-Identifying>>

Enfournement

Dh_Enf : DATETIMEDh_Enf_Divers : DATETIMEDh_Def_Planifiee : DATETIMEId_Four : INTCode : VARCHAR(255)

1

0..1

1

0..1

<<Identifying>>

1

0..*

1

0.. *

<<Non-Identifying>>

10..* 10..*

<<Non-Identifying>>

PlaceProduction

Code : VARCHAR(255)

1

0..1

1

0..1

<<Identi fying>>

Entreprise

Nom : VARCHAR(255)

PlaceOfCoke

Code : VARCHAR(255)

1 0..11 0..1<<Identifying>>

0..*

1

0..*

1


Envoi

Numero : FLOAT(53, 0)Nom : VARCHAR(255)

0..1

0..*

0..1

0..*

<<Non-Identifying>>

0..1

0..*

0..1

0..*

<<Non-Identifying>>

0..1

0..*

0..1

0..*

<<Non-Identifying>>

SubMvtCharbon

Numer o : FLOAT( 53, 0)Poids : BIGINTDateTime : DATETIMENumer oMvtChar bon : F LOAT(53)Code : VARCHAR( 255)

1

0..*

1

0..*

<<Non-Identifying>>

AnalyseCharbon

Quant ite : BIGINTNom : VARCHAR(255)Numero : FLOAT( 53)

Charbon

Number : FLOAT(53)cod_pay : INTNom : VARCHAR(255)

0..*

1

0..*

1<<Non-Identifying>>

PlaceOfMelange

Code : VARCHAR(255) 1 0..*1 0..*

<<Non-Identifying>>

1

0..1

1

0..1

<<Identifying>>

Element

Nom : VARCHAR(255)1

0..*

1

0..*

<<Identifying>>

Granulometrie

Interval : VARCHAR(255)Nom : VARCHAR(255)

Sales

Poids : BIGINTDateTime : DATETIMENom : VARCHAR(255)Numero : FLOAT(53, 0)

1

0.. *

1

0.. *

<<Identi fying>>

Coke

Numer o : FLOAT( 53)IR SID_I10 : BIGINTIR SID_I20 : BIGINTIR SID_I40 : BIGINTNom : VARCHAR(255)

SubMvtCoke

Numero : FLOAT(53, 0)Poids : BIGINTDateTime : DATETIMENumeroMvtCoke : FLOAT(53)Code : VARCHAR(255)

1

0.. *

1

0.. *

<<Non-Identifying>>

AnalyseCoke

Quantite : BIGINTNom : VARCHAR(255)Numero : FLOAT(53)

1

0..*

1

0..*

<<Identifying>>

GranCoke

Quantite : INTInterval : VARCHAR(255)Numero : FLOAT(53)

0..1

1

0..1

1

<<Identifying>>

MvtCharbon

Numero : FLOAT(53, 0)Poids : BIGINTDateTime : DATETIMENumber : FLOAT(53, 0)NumberEnvoi : FLOAT(53, 0)

0..1

1

0..1

1

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

0..*

1

0..*

1

<<Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

SubMvtMelange

Numero : FLOAT(53, 0)Poids : BIGINTDateTime : DATETIMENumeroMvtMelange : FLOAT(53)Code : VARCHAR(255)

1

0..*

1

0..*

<<Non-Identifying>>

Melange

Numero : FLOAT(53)SwellingIndContMax : BIGINTSwellingIndDilMax : BIGINTNom : VARCHAR(255)

AnalyseMelange

Quantite : BIGINTNom : VARCHAR(255)Numero : FLOAT(53)

1

0..*

1

0..*

<<Identifying>>

GranMelange

Quantite : INTInterval : VARCHAR(255)Numero : FLOAT(53)

0..1

1

0..1

1

<<Identifying>>

MvtCoke

Numero : FLOAT(53)Poids : BIGINTDateTime : DATETIMERetourn : BITNumeroCoke : FLOAT(53)NumeroMelange : FLOAT(53)

1 0..*1 0..*

<<Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

0..*

1

0..*

1

<<Identifying>>0..*

1

0.. *

1

<<Identifying>>

ComposeMelange

Quantite : INTNumeroCharbon : FLOAT(53)NumeroMelange : FLOAT(53)

0..*

1

0..*

1<<Identifying>>

MvtMelange

Numero : FLOAT(53)Podis : BIGINTDateTime : DATETIMENumeroMelange : FLOAT(53)

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

0..*

1

0..*

1

<<Identifying>>

0..*

1

0..*

1

<<Identi fying>>

0..11 0..11

<<Non-Identifying>>

0..*

1

0..*

1

<<Identifying>>

10 - 30

Database Designer (Class Diag.)Database Designer (Class Diag.)

(J) Iteration 5 : Transition (J) Iteration 5 : Transition Implementation Implementation

10 - 31

System Designer (System Designer (SeqSeq. . DiagDiag.).)

: EnfourneuseE3 : EnfourneuseE1

: Contremaitre

Enfournement P lanningD efou rn ement

1: en fournem entE3()

2: enfournementE1()

3: validationEnfournement()

(K) Iteration 1 : Elaboration(K) Iteration 1 : Elaboration

Analysis Analysis

(L) Iteration 2 : Elaboration(L) Iteration 2 : Elaboration

Design Design

: Defouneuse : Guide Coke

: Contremaitre

Defournement_Puissance


Defournement_ProfilCoke


1: enregistrementPuissance()

3: enregistrementProfilCoke()

2: enregistrementTemperatureCotherm()

4: validationDefournement()

: équipe four : Défourneuse : Guide_Coke : Coke_Car : Four

1. aligner(Four)

2. aligner(Four)

3. aligner(Four)

4. ouvrir( )

4.3. défourner( )

4.3.1. transférer_saumon(Saumon)

4.3.1.2. récept ionner_mp(Saumon)

4.3.1.2.1. fermer( )

4.1. ouvrir_four( )

4.2. ouvrir_porte( )

4.4. fermer_four( )

4.5. fermer_porte( )

4.3.1.1. prendre_profil(Saumon)

10 - 32

Defournement_Puissance

: Uti lisateur


PdefResultat


PdefListeResult

Enfournement


TCxListeS erieTempPyrometre

RecapPauseCoProduit

20: moyenneTempCotherm()21: ecartTypeTempCotherm()23: moyenneTempCotherm()24: ecartTypeTempCotherm()

19: carteCotherm Batterie()22: carteCothermFour()

25: courbesTemperatureSaumon()26: historiqueCourbesTemperatureSaumon()

27: checkCarneaux()

28: cartePuissanceBatterie()29: cartePuissanceFour()

30: evolution3DPic()31: evolution3DPAD()

32: evolut ion3DID()33: evolut ionPuis sanceMoyenneBat terie()

34: picMoyDerniersDefournements()35: nbreFoursCalesParMoisPuissanceMois()

5: enregistrePlanningValide()7: imprimePlanning()

1: startModelePV()3: startModeleLight()

8: setResultat()

16: txUtilisationE3()

9: val idationEnfournement()10: validationDefournement()

11: encoderSerieTempCx()13: validerSerie()

14: encoderCommentaire()17: historiqueCx5-22()

15: encoderCahierElectronique()

6: setPlanning2: enregist rePlanningPropose()4: enregist rePlanningPropose()

12: enregistrerTempCx()18: getTempSerie()

System Designer (System Designer (SeqSeq DiagDiag.).)

(N) Iteration 2 : Construction(N) Iteration 2 : Construction DesignDesign

: Utilisateur

P defLis teResult P defResu lt at P l anni ngDefourneme nt

TCxLis teS erieTem pP yrom etre

TCxS erieTem pP y rom etre

RecapP auseCoP roduit

Defournem ent_Cotherm

Defou rnem ent_P uissance

E nfournem ent

19: carteCotherm B atterie()

25: courbesTem peratureS aum on()

28: carteP ui ssanceB at te rie()

29: carteP uissanceFour()

30: evolut ion3DP ic ()

31: evolution3DP A D()

32: evolution3DID()

33 : e volutionP ui ssanceM oyen neB att erie( )

34: picM oyDerniersDefournem ents()

35: nbreFoursCalesP arM oisP uissanceM ois()

16: txUt ilisationE 3()

1: s tartM odeleP V ()

2: enregis treP lanningP ropose()

3: s tartM odeleLight()

4: enregis treP lanningP ropose()

5: enreg is t reP lanningV al ide ()

6: se tP l annin g

7: im prim eP lan ning( )

8: setResultat()

9: validationE nfournem ent()

10: validat ionDefournem ent()

11: encoderS erieTem pCx()

1 2: enre gis t rerTem pCx()

13: validerS erie()

14: encoderCom ment aire( )

15: encoderCahierE lec tronique()

17: his to riqueCx5-22()

18: getTem pS erie()

20: m oyenneTem pCotherm ()

21: ecar tTy peTem pCotherm( )

22: carteC ot herm Four ()23: m oyenneTem pCotherm ()

24: ecartTypeTem pCotherm ()

26 : h is toriqueCou rbesTe mperat ureS aum on()

27: checkCarneaux ()

(M) Iteration 1 : Construction(M) Iteration 1 : Construction AnalysisAnalysis

10 - 33

Syst. ArchitectSyst. Architect((ImplImpl. . DiagDiag))

Uses UsesUsesUses

Uses UsesUsesUses

Uses

Syncfusion.chart

Base de données

Base de données SQL server

Interfaces graphiques

Interfaces pour ingénieur de gestion Interfaces pour contremaître

Planification Entretiens

Choix de la fonctionnalité

Rapport journalier

Comparaison de fours

Historique défournements

Rapport défournement

Rapport entretien

Connexion

Choix de la fonctionnalité

Contrôle

Gestionnaire de graphiques

Gestionnaire de requêtes

d’accès à la base de données

Gestionnaire des entretiens

Gestionnaire des accès sécurisés

Gestionnaire de détection et de diagnostic des

problèmes

Uses Uses Uses

IdentificationsDonnées de

défournementEntretiens

Problèmes rencontrés sur

les fours

Domain dependant storage

Instantiates

AD

O.N

ET

System.windows.forms

Instantiates(O) Iteration 1 : (O) Iteration 1 :

ConstructionConstruction

ImplementationImplementation

10 - 34

Network Architect (Imp. Network Architect (Imp. DiagDiag))

Réseau ethernet

Contremaître

PC du contremaître

Identification contremaître

Serveur d’identification

Identification Ingénieur de production

Accès spécifiquecontremaître

Gestion accèscontremaître

Terminal machiniste Machiniste

Accès spécifiqueIngénieur de production

Gestion accèsIngénieur de production

Serveur de l’application du machiniste

Automate pyromètre et profilocoke situé

sur guide-coke

Automate ampèremètre situé sur le moteur de la

défourneuse

Serveur de l’application de gestion des fours

Serveur de la base de données



Machiniste

Contremaître

VAX

PC de l’ingénieur de production

Base de données

Application sécurisée Gestion des accès Base de données

Un seul même serveur physique

(P) Iteration 2: Construction(P) Iteration 2: Construction DeploymentDeployment

10 - 35

Soft. Engineer (Code)Soft. Engineer (Code)

(Q) Iteration 1 : Transition(Q) Iteration 1 : Transition ImplementationImplementation

10 - 36

Web Engineer (Code)Web Engineer (Code)

Intranet Deployment of the identified application Intranet Deployment of the identified application functionalitiesfunctionalities

(R) Iteration 2 : Transition(R) Iteration 2 : Transition DeploymentDeployment

10 - 37

Web Engineer (Code)Web Engineer (Code)

Web EWeb E--Commerce DeploymentCommerce Deployment(S) Iteration 3 : Transition(S) Iteration 3 : Transition DeploymentDeployment