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

Module 0 : About This Course

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-2

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-3

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

0-4

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

Module 1 : Getting Started with Rational Software Architect

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-2

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-3

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-4

The Workspace
When 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 The workspace itself is a directory, which defaults to the name workspace. You defaults to the name workspace. You may locate it anywhere you want. It may may locate it anywhere you want. It may contain either new projects as subcontain either new projects as subdirectories, or just references to projects directories, or just references to projects that exist elsewhere on the file system. that exist elsewhere on the file system.

1-5

Basic User Interface: The Welcome View

After the workspace dialog, the Welcome view will be the first thing you see.
Get an overview Get an overview of the features of the features Make first steps Make first steps Find out what is new Find out what is new

Overview Overview

First Steps First Steps

Whats New Whats New

Go to the workbench Go to the workbench

Workbench Workbench

Read more on the web Read more on the web

Web Resources Web Resources

Try out the samples Try out the samples

Samples Samples

Migrate to the new release Migrate to the new release

Migrate Migrate

The Welcome View

Go through tutorials Go through tutorials

Tutorials Tutorials

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.
1-6

Basic User Interface: The Workbench

The 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 A shortcut bar appears in the top appears in the top right corner of the right corner of the window. This allows window. This allows you to open new you to open new perspectives and perspectives and switch between switch between ones already open. ones already open. The name of the The name of the active perspective is active perspective is shown in the title of shown in the title of the window, and is the window, and is highlighted in the highlighted in the shortcut bar. shortcut bar.

The Workbench

1-7

Perspectives
A 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 Java For working with Java projects CVS Repository Exploring For checking projects in and out securely

Java Browsing For browsing the structure of Java projects Debug For debugging a program Plug-In Development For developing Eclipse plug-ins

1-8

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 or view that is active is the one An editor or view that is active is the one whose title bar is highlighted. Here, the whose title bar is highlighted. Here, the Navigator view is active. Navigator view is active.

An editor is used to edit or browse a resource.

1-9

Editors
Editors allow document editing from within the workbench for various types of artifacts, including text and diagrams.
The name of the file appears The name of the file appears in the tab of the editor. If an in the tab of the editor. If an asterisk (*) appears at the left asterisk (*) appears at the left side of the tab, this indicates side of the tab, this indicates that the editor has unsaved that the editor has unsaved changes. changes.

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

1 - 10

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 The New Project wizard helps you create a new C or C++ project in the workbench. To new C or C++ project in the workbench. To access the wizard, select File > New > access the wizard, select File > New > Project from the menu. Project from the menu.

1 - 11

Importing and Exporting Projects

You 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 - 12

Lab 01: Creating a Project

The instructor will walk through this lab together with the class in order to The instructor will walk through this lab together with the class in order to demonstrate cheat sheet navigation. demonstrate cheat sheet navigation. 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.
1 - 13

Help
There are extensive Help resources that include:
Help Contents Tips and Tricks Cheat Sheets Dynamic Help

1 - 14

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 - 15

Lab 02: Customizing Perspectives

In 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:

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 02 Customize Perspectives. Follow the directions indicated on the Cheat Sheet.

1 - 16

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 - 17

Model-Driven Development in Rational Software Architect

Create the domain model
Transformation

Traceability relationships created as a byproduct of patterns and transformations

Create the use-case model

Transformation

Create the design model

Transformation

Complete the implementation using UML visualization

1 - 18

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

Module 2 : Model Structure and Templates

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

2-2

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 model Code Data model

2-3

What is a UML Model in Rational Software Architect ?

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

UML Models in Rational Software Architect:

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

Closed model Closed model Physical Model File Open model Open model (Logical) Model

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

2-5

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 systems 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 UML Model UML Model Fragment UML Profile Class Diagram Topic Diagram Object Constraint Language (OCL) resource Transformation Configuration Reusable Asset RAS Manifest Extension .emx .efx .epx .dnx .tpx .ocl .tc .ras .rmd

2-6

The Modeling Perspective

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

Editors

Views

2-7

Comments
The Rational Software Architect workbench window contains one or more perspectives. A perspective defines 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 Java perspective 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-8

Views in the Modeling Perspective

Views in the Modeling Perspective:
For exploring modeling projects:
Project Explorer view
Diagrams Models

For exploring resources:

Pattern Explorer view Outline view Inheritance Explorer view Properties view

For getting feedback:

Tasks view Output window

2-9

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 - 10

Project Explorer View

Used for navigating and organizing models.
Diagram Closed Model Open Model Package Class Relationship Diagram

Attribute

2 - 11

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 - 12

Properties View
Displays properties and values for the selected element.

2 - 13

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 - 14

Diagram Editor
Drawing Surface
Palette

Drawers

Tools

2 - 15

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 - 16

Outline View
When the diagram editor is open, the Outline view can show either:
A thumbnail graphical view of the diagram A tree view listing the elements of the diagram

2 - 17

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 - 18

UML Model Editor

2 - 19

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 - 20

Rational Unified Process Resources

Process guidance is built in the:
Rational Software Architect Process Advisor feature Rational Software Architect Process Browser feature

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

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 - 22

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 UML Project

Implementation projects:
Java, EJB (Enterprise JavaBeans) technology , and so on Implementation projects can contain UML class and sequence diagrams

Java Project

Simple Project New Project wizard

Simple projects can be of either type.

2 - 23

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 codes 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 - 24

Model Templates in Rational Software Architect

UML Project templates are available in the New Project wizard. The following model templates are available:
Analysis Model Blank Model CORBA Template Model DoDAF Model Enterprise IT Design Model Service Design Model Use Case Model XSD Model
2 - 25

UML Profiles
UML profiles are often included with module templates Profiles 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 element Tagged values: To add properties that are not supported by the base element Constraints: Constraints enforced on the element or its attributes

2 - 27

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 elements 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 - 28

How Are Profiles Used ?

Profiles are used to model platformor model-specific abstractions, for example:
Enterprise beans Analysis classes
Model Template
Profile added to the template and models created from it. Elements in the model can have stereotypes from the profile, with constraints ensuring correct usage.

Profiles provide a domain-specific language for reusable assets:

Add to model templates Use with domain-specific patterns Use a transformation to create a platform-specific model
Profile

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

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

Transformations
Designed to recognize and transform elements with stereotypes from the profile.

2 - 29

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.

2 - 30

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

Module 3 : Creating UML Diagrams

Module Objectives
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

3-2

UML Diagrams in Rational Software Architect

A model element appears in zero or more diagrams
Diagrams graphically depict a view of a part of your model or code Different diagrams represent different views of the system that you are developing

3-3

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 highlevel insight into the concept and design of an application.

3-4

UML Diagrams in Rational Software Architect

Structural Diagrams
Use-Case Diagrams Sequence Diagrams Class Diagrams Object Diagrams

Communication Diagrams

Model

Component Diagrams

State Machine Diagrams

Composite Structure Diagrams Activity Diagrams

3-5

Behavioral Diagrams

Deployment Diagrams

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 Diagrams Rational 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 Diagrams Rational 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-6

Creating UML Model Diagrams

Use diagrams to represent different views of the system or application:
UML diagrams Non-UML (freeform) diagrams

Create diagrams in:

Models Model elements
Packages Components Active classes And so on

Creating a diagram in the Project Explorer view.

3-7

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-8

Review: Diagram Editor

Drawing Surface
Palette

Drawers

Tools

3-9

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 - 10

Adding Model Elements to a Diagram

1
Drag an existing Drag an existing element from the element from the Project Explorer view. Project Explorer view.

Click a tool in the diagram Click a tool in the diagram editors tool palette and then editors tool palette and then click inside the diagram. click inside the diagram.

Hover or click the mouse in the diagram to make the action bar appear. 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 Select the element to insert. Hover over the new model element to use the action bar to add details (attributes and operations). the action bar to add details (attributes and operations).
3 - 11

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 - 12

Deleting from the Diagram and the Model

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

Delete from Model

Remove the item from the diagram and the model

Deleting an Element in the Diagram Editor

3 - 13

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 - 14

Diagram Validation: Validating Model Semantics

Examine 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 - 15

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 - 16

Lab 3: Create UML Diagrams

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

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog. Click Select a Cheat Sheet from the list. Expand DEV396 Labs, then select Lab 3: Create UML Diagrams. Follow the directions indicated on the Cheat Sheet.

3 - 17

UML Visual Development Visualize Java and C++ code in UML diagrams Visualize code with diagrams that are either:
Project resources
Class (.dnx) Sequence (.tpx)

New diagrams in an existing model (.emx)

Class Sequence Freeform Topic

3 - 19

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 systems components and interrelationships, and to create representations of the system in another form. You can use UML diagrams to automatically abstract the systems 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 - 20

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 - 21

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 - 22

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 - 23

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 - 24

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 a group 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 - 25

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 - 26

Browse Diagrams
Browse diagrams can be used to:
Show the elements related to the selected element Show the dependencies to the selected element Gain a detailed understanding of the element in focus

Browse diagrams are driven by parameters and filters that you control.
Select relationships to display Select relationships to display and levels of relationships, and and levels of relationships, and then click Apply. then click Apply.

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

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

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 - 28

Lab 4: Create Browse and Topic Diagrams

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

To begin the lab:

In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog. Click Select a Cheat Sheet from the list. Expand DEV396 Labs, then select Lab 4: Create Browse and Topic Diagrams. Follow the directions indicated on the Cheat Sheet.

3 - 29

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

Module 4 : Creating UML Diagrams of System Structure

Module Objectives
After completing this module, you will be able to:
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-2

Structural UML Diagrams

Structural Diagrams
Use-Case Diagrams Sequence Diagrams Class Diagrams Object Diagrams

Communication Diagrams

Model

Component Diagrams

State Machine Diagrams

Composite Structure Diagrams Activity Diagrams

4-3

Behavioral Diagrams

Deployment Diagrams

Comments
Rational 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

4-4

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-5

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-6

Class Icon
Class Name Class Name Template Class Parameter Template Class Parameter

4-7

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-8

Other Class Diagram Model Elements

Signal 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-9

Class Relationships
Class diagrams may contain the following relationships:

Association Aggregation Composition Generalization Dependency Realizes

4 - 10

OR OR OR

Association

OR

Specifies peer-to-peer relationships between model elements Navigability can be unidirectional or bidirectional

4 - 11

Aggregation

OR

Used to model a whole to part relationship between model elements The part element can exist without the whole Navigability can be unidirectional or bidirectional

4 - 12

Composition

OR

Aggregation with strong ownership When the container is destroyed, all of its composite objects are destroyed Navigability can be unidirectional or bidirectional

4 - 13

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 - 14

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 - 15

Realization
A specialized relationship where the client implements the suppliers specification

4 - 16

Lab 05: Create a Class Diagram

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

Complete the following tasks:

Review Class Diagram Basics Create a New Class Diagram Challenge Yourself

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 05 Create Class Diagrams. Follow the directions indicated on the Cheat Sheet.
4 - 17

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 Object Name

Link

Attribute Values
4 - 19

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 - 20

Composite Structure Diagram

A 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 - 21

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 StudentManagementSystem, BillingSystem, and CourseCatalogSystem. A later slide will examine the internal structure of the StudentManagementSystem. of three parts:

4 - 22

Lab 06: Create Composite Structure Diagrams

Complete the following tasks:
Review Composite Structure Diagram Basics Create a New Composite Structure Diagram Challenge Yourself

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 Lab 06: Create Composite Structure Diagrams Follow the directions indicated on the Cheat Sheet.

4 - 23

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 - 24

Lab 07: Create Component Diagrams

Complete the following tasks:
Review Component Diagram Basics Create a New Component Diagram Challenge Yourself

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 Lab 07: Create Component Diagrams Follow the directions indicated on the Cheat Sheet.

4 - 25

Deployment Diagrams
Deployment 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 - 27

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 - 28

Lab 08: Create Deployments Diagrams

Complete the following tasks:
Review Deployment Diagram Basics Create a New Deployment Diagram Challenge Yourself

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 Lab 08: Create Deployment Diagrams Follow the directions indicated on the Cheat Sheet.
4 - 29

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

Module 5 : Creating UML Diagrams of System Behavior

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-2

Behavioral Diagrams in Rational Software Architect

Structural Diagrams
Use-Case Diagrams Sequence Diagrams Class Diagrams Object Diagrams

Communication Diagrams

Model

Component Diagrams

State Machine Diagrams

Composite Structure Diagrams Activity Diagrams

5-3

Behavioral Diagrams

Deployment Diagrams

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 Class diagrams to illustrate logical structure 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 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-4

Use Case Diagrams

Use 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-5

Use-Case Diagram Elements

Use Case Use Case

Units of system behavior Units of system behavior

Actor Actor

Someone or something that Someone or something that interacts with the system interacts with the system
5-7

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-8

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
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 Lab 9: Create Use-Case Diagrams Follow the directions indicated on the Cheat Sheet.

5-9

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 - 11

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 - 12

Activity Diagrams

5 - 13

Comments
Activity diagrams are particularly useful in describing workflow, and a use cases 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 - 14

Action
An action is a fundamental unit of executable functionality It represents some transformation or processing in the modeled system
An action is a UML Element that you put INTO activity diagrams An action represents behavior that you do NOT want to model in more detail it is fundamental or atomic

5 - 15

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 action Double-click a call behavior action to open the linked activitys diagram

5 - 16

A Call Operation Action

A 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 - 17

Accept Event and Send Signal Actions

Accept event
An action waiting for an event Actions that may be used by themselves, or may be paired with send signal actions

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

5 - 18

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 - 19

Partitions

5 - 20

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 another Can have guard conditions
Control Flow

5 - 21

Control Nodes
Control nodes coordinate the flow in an activity

Initial

Fork/Join

Flow Final

Decision/Merge
5 - 23

Activity End

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 - 24

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

5 - 25

Lab 10: Create Activity Diagrams

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
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 Lab 10: Create Activity Diagrams Follow the directions indicated on the Cheat Sheet.

5 - 26

Interaction Diagrams (1 of 2) Interaction diagrams show how objects interact, and the order of their interactions There are several types of interaction diagrams that emphasize object interactions, including the messages that may be dispatched among them:
Sequence diagram Communication diagram Interaction overview diagram

5 - 27

Interaction Diagrams (2 of 2) Sequence diagram

Time-oriented view of interactions
comm sd

Communication diagram
Structural view of messaging roles or parts

Interaction overview diagram

High-level view of interaction sets combined with logic
5 - 28

intover

Sequence Diagrams Versus Communication Diagrams

Sequence Diagrams
Show the explicit sequence of messages Better for visualizing overall flow Better for real-time specifications Better for complex scenarios

Communication Diagrams
Show relationships in addition to interactions Better for visualizing patterns of collaboration Better for visualizing all of the effects on a given role or part Easier to use for brainstorming sessions

5 - 29

The Anatomy of Sequence Diagrams

Lifeline Message Role Reflexive Message

Event Occurrence

Execution Occurrence
5 - 30

Hierarchical Message Numbering

Example: Sequence Diagram

5 - 31

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 - 32

Combined Fragments
Combined fragments represent a grouping of behavior shown as a nested region within a sequence diagram:
Define conditional structures in interactions Describe several traces in a compact and concise manner
Interaction Operator Guard Expression Combined Fragment

Interaction Operand

Combined Fragment
5 - 33

An Interaction Operator An interaction operator identifies the type of combined fragment

The loop operand indicates that the Fragment is executed repeatedly The alternative operand identifies a set of behaviors from which only one will execute on any one pass through the interaction
5 - 34

The Guard Expression The guard expression is a Boolean conditional expression that guards an interaction operand:
Appears at the start of the operand Is used to determine if, or how long, the operand will be executed Its absence equates to a true condition
5 - 35

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 - 36

Communication Diagram

5 - 37

Lab 11: Create Sequence Diagrams

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.

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 Lab 11: Create Sequence Diagrams Follow the directions indicated on the Cheat Sheet.

5 - 38

Lab 12: Create Communication Diagrams

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

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 Lab 12: Create Communication Diagrams Follow the directions indicated on the Cheat Sheet.

5 - 39

A State Machine Diagram

State: a recognizable situation that exists over an interval of time ~ Hassan Gomaa State transitions: Possible paths the system may take from one state to another Triggering events: Instantaneous events that stimulate state transitions Actions: Work the system does in response to events

5 - 40

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 - 41

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

5 - 42

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 - 43

Composite States
Composite states are states that contain other states and regions

5 - 44

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

5 - 45

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 - 46

Pseudostates
Initial State: Marks the start of the machine Choice Point: Supports dynamic branches Junction Point: Supports static branches Deep History: Return to the most recent substate Shallow History: Return to the most recent state Join, Fork: Similar to activity diagram Entry, Exit Point: Used to designate a default entry or exit into a composite state or state machine Terminate: Marks the end of the state machines execution
5 - 47

Combine and direct transitions

Choice Points
Choice 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 - 48

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 - 49

History
Deep History
Represents the most recent active configuration of the composite state that directly contains this pseudostate A 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 - 50

Lab 13: Create State Machine Diagrams

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

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 Lab 13: Create State Machine Diagrams Follow the directions indicated on the Cheat Sheet.

5 - 51

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

Module 6 : Team Development

Module Objectives
After completing this module, you will be able to: 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-2

Software Architect and Team Development

Architect
Create and publish models

Developer
Consult published models and artifacts

Transform design model into code

Elaborate the code

Verify architecture and code with structural code review

Repository

Verify code with code review

6-3

Comments
The following Rational Software Architect features facilitate collaboration between architects and developers : Transformation Rational Software Architects 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 Review The code review feature is used to analyze code against the projects 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 Publisher While creating detailed implementation code, the developer can refer to Web-published models and UML injected Javadocs, which Rational Software Architect can generate automatically.

6-4

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-5

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 subsystems 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-6

Model Partitioning
To partition a model, you can: Create fragments
An element that has been converted into a fragment has this icon:

Create new models from packages

A 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
Creating a model from a package automatically leaves Creating a model from a package automatically leaves a shortcut reference to the new model where the a shortcut reference to the new model where the package used to be. package used to be. Creating a fragment from a model element adds an adornment to Creating a fragment from a model element adds an adornment to the element and creates a separate file for that element. the element and creates a separate file for that element.
6-7

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-8

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 Design Model.emx is the original model that you started with. that you started with.

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

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

6-9

Fragments
Fragments 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
When viewing details of a When viewing details of a model in the UML model model in the UML model editor, you can see fragments editor, you can see fragments associated with it by clicking associated with it by clicking the Fragments tab at the the Fragments tab at the bottom of the editor. bottom of the editor.

Diagrams that cannot be made into Fragments:

Class Diagram Object Diagram Freeform Diagram Deployment Diagram Component Diagram
6 - 10

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 - 11

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 - 12

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

Contributor 1 Contributor 1

Contributor 2 Contributor 2

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

2 1 3

Merge

6 - 13

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 colleagues changes. The SCM system attempts to merge your changes into the latest version (BC version 3) in the repository.

6 - 14

Compare Editor

Merged Model Merged Model Structural Differences Structural Differences Accept or Reject changes Accept or Reject changes

Left Contributor Left Contributor

Right Contributor Right Contributor

6 - 15

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 merges During 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 merges During 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 - 16

Compare and Merge Features

Diagram 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 - 17

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 dont 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 - 18

Lab14: Compare and Merge a Model

In this lab, you will learn how to compare and merge a model using the Model Compare editor. After completing this lab, you will be able to:
Compare models Merge models

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 14 Compare and Merge Models. Follow the directions indicated on the Cheat Sheet.
6 - 19

Combine Models
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.

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

Source Model Source Model

Target Model Target Model

Change Description Change Description

6 - 20

Lab15: Combine Models

In this lab, you will learn how to combine dissimilar models. After completing this lab, you will be able to:
Combine models

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 15 Combine Models. Follow the directions indicated on the Cheat Sheet.
6 - 21

Model Publishing
Publish the entire model to HTML Publish reports to PDF
Model diagram report Sample UML metric report

6 - 23

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, the root 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 - 24

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. After completing this lab, you will be able to:
Publish a model Generate a model report

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 16 Publish and Generate Reports. Follow the directions indicated on the Cheat Sheet.
6 - 25

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

Module 7 : Applying Patterns and Transformations

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-3

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-4

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 problem Requires a strategy for applying the pattern in its context. Comes with consequences (advantages and disadvantages) of applying the pattern.

7-5

Patterns in Rational Software Architect

Three 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 model
1. Model-to-model 2. Model-to-code 3. Code-to-model

Pattern
1

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

Transformations

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 Patterns Design 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. Transformations Transformations 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 platformspecific 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-8

The Pattern Explorer view

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

Design Pattern

Transformation

JET Transformation
Icons in the Pattern Explorer view
7-9

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 patterns 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 - 10

Design Patterns in Rational Software Architect

A design pattern in Rational Software Architect adds details to a model automatically. Use design patterns to add:
Model elements and relationships
Classes, packages, and so on

Details to model elements

Attributes, operations

Markup to the model

Stereotypes from a UML profile recognized by transformations

A design pattern:
Has parameters that are used to bind the pattern to the model Can be reapplied to or unbound from the model Usually affect small areas of the model when applied
7 - 11

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 - 12

Design Pattern Notation

Pattern Instance
A UML Collaboration

Parameters

Multiplicity

Bound Arguments Binding Indicator

Parameter Type
7 - 13

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 parameters 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 - 14

Applying a Design Pattern

1
Create 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.

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

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

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 patterneither 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 instances 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 - 16

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

Example
Observer is a GoF behavioral design pattern:
One-to-many dependency between objects When one object changes state, observers are notified and updated automatically
7 - 17

Comments
The 23 Gang of Four design patterns are included with Rational Software Architects 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 - 18

Lab 17: Apply Patterns

Complete the following tasks:
Examine the Observer design pattern Create the UML modeling project Select a Pattern Apply a Pattern View Pattern Relationships

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 Lab 17: Apply Patterns. Follow the instructions indicated in the cheat sheet.

7 - 19

Transformations
Transformations 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 standard Based on the analysis model, create a design model that incorporates elements of the companys security and persistence frameworks, and follows a modeling standard Starting with a UML model, apply a builtin transformation to create code elements Take existing code and apply a transformation to abstract out the design elements.

Transformations
7 - 20

Transformations in Rational Software Architect

The following transformations are built in to Rational Software Architect:
UML to UML
UML to LDM

UML to code
UML to Java V1.4 UML to Java V5.0 UML to C++ UML to EJB UML to WSDL UML to XSD

Code to UML
C++ to UML Java to UML

UML to SQL / DB / Relational

Transformations can be custom built using the Plug-in Development Environment.

7 - 21

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

Synchronize
model to model comparison and sync, model to database comparison and sync

Model
logical and physical data model, entity relationship diagram, storage diagram, domain model

XML
XML schema editor XML mapping XML shredding

Relate
model to model mappings, mapping discovery, ER to XML mapping

Code
SQL editor, stored procedures wizard, debugger for DB2

Store
models SQL and XML files

Team
versioning governance

Integrate
requirements transformations

Import/Export
models glossary

7 - 22

Create a Database Model

Initiate information design with a transformation from system architecture models or Reverse engineer your current databases to create a data model or Import your existing data model from other tools or Create the model based on a model template

7 - 23

Integration with Rational Software Modeler

Rational Software Modeler and Rational Data Architect installation in the same shell instance
Same user experience as in Rational Data Architect Modeling perspective includes functionality for data modeling and UML data modeling Data perspective includes the same physical metamodels and features as in Rational Data Architect

7 - 24

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 model Generate data access model or service model from logical data model (LDM-to-UML)
7 - 25

Reverse Transformations
Java and C++ transformations can be reversed Enable a reverse transformation in the transformation configuration Allows you to synchronize changes between UML models and C++ and Java code
If necessary, compare and merge session starts when transformation is run
7 - 27

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 - 28

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.
Pending Changes Pending Changes Mark changes from source Mark changes from source model to be applied to model to be applied to target model. target model.

Source Model Source Model

Target Model Target Model

Change Description Change Description

7 - 29

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 - 30

UML Visual Development

C++ and Java code can be visualized with class and sequence diagrams
Changes to the code update the diagram Changes to the diagram update the code Harvest classes into UML models

7 - 31

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 - 32

Lab 18: Run a UML to Java Transformation

Complete the following tasks:
Task 1: Create the UML modeling project Task 2: Create UML Classes Task 3: Transform UML Classes to Java Classes Task 4: Perform reverse transformation To begin the lab:
In Eclipse, click Help > Cheat Sheets to open the Cheat Sheet Selection dialog. Click Select a Cheat Sheet from the list. Expand DEV396 Labs, then select Lab 19: Run a UML to Java Transformation. Follow the directions indicated on the Cheat Sheet.

7 - 33

UML to Database Generation with RSA and RDA

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 - 35

Figure 1. Sample Class Model in RSA Invoice project

Figure 1 below shows a few sample classes, and their associations, Invoice, InvoiceItem, ProductInvoice and 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 - 36

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 - 37

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 todays 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 - 38

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 UMLto-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 - 39

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 - 40

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 dont 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 - 41

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 theres 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-toUML transformation. 3. The Application Modeler accesses and imports the class model in RSA.

7 - 42

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 - 43

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 enterpriselevel. 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 LDMs hold 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 doesnt 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 - 44

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 - 45

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 - 46

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 Transformations Model 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 - 47

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, UnlimitedNatural o User defined data types: primitive types or enumerations Please refer back to Figure 1 for the sample class model.
7 - 48

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 - 49

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 - 50

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 - 51

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 - 52

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 - 53

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 - 54

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 - 55

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 - 56

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 - 57

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 - 58

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 - 59

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 - 60

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 jumpstart 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 - 61

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

7 - 62

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

Module 8 : Traceability

Module Objectives
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 Modeler Use topic and browse diagram to investigate traceabilities.

8-2

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-3

Product Integrations with Rational Software Architect

WebSphere Business Modeler

RequisitePro

BPEL
BPEL has only stuff that is to be automated

UML (contract)
one-way flow

IBM WebSphere Integration Developer

WSDL Rational Software Architect

IBM WebSphere Business Monitor

IBM WebSphere Process Server IBM WebSphere Application Server

RUNTIME
8-5

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. WebSphere Business 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-6

Traceability from Requirements to Design

Problem Problem Needs Features Software Requirements Design The system to be built Traceability

Problem Space

Solution Space

Test Procedures
8-7

User Doc

Rational RequisitePro Integration

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

Features and Vision

Vision Document FEAT 1 FEAT 3 FEAT 7

The Requirements perspective in Rational Software Architect:

Provides an effective interface to requirements managed in RequisitePro, including:
Documents
Vision, use-case specifications

Requirements Requirement Properties Views

All Features

Use Cases

Allows requirements to be traced to model elements

8-8

Views of the Requirement Perspective

Requirement Explorer

Requirements Properties

Requirements Trace

Link Clipboard

Query Results

Requirement Link Problems

8-9

RequisitePro

Requirements Explorer
8 - 10

Query Results

Associating Requirements and Model Elements

Creating a new model element

Associating with an existing element

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

Drop a requirement on to an existing model element to associate that Drop a requirement on to an existing model element to associate that element with the use case in RequisitePro. element with the use case in RequisitePro. You can associate requirements with use cases, classes, diagrams, You can associate requirements with use cases, classes, diagrams, and relationships (associations, messages, and so on). and relationships (associations, messages, and so on).
8 - 11

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 - 12

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 linked Proxies are RequisitePro requirements Mapping between model elements and requirement types are managed using the RequisitePro project properties Additional attributes may be added to the proxy requirement types.

8 - 13

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 - 14

Lab 19: Create Traceability Links

Given:
Existing RequisitePro project

Complete the following tasks:

Explore Requirement Perspective Link Folders and Files to Requirements Link UML Model Elements to Requirements Link Java Classes to Requirements Review Requirements

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 Lab 19: Create Traceability Links. Follow the instructions indicated in the cheat sheet.

8 - 15

WebSphere Business Modeler

People who know the business create the models
Model Resources, roles, organization information, business metrics Enables teamwork, communication, versioning and Web publication

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

8 - 16

WebSphere Business Modeler and Rational Software Architect

1. Business analyst creates business model 2. Software Architect views business model as UML
WebSphere Business Modeler
View as UML Contract

Rational Software Architect

3. Requirements analyst gathers requirements based on business model 4. Software Architect creates UML design model

Business Process Model

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

Business Process models serve as Business Process models serve as contracts for software contracts for software implementation of roles / /tasks implementation of roles tasks

8 - 17

Business Process Model Elements

Process diagram generated by WebSphere Business Modeler Stop
Decision Task Node

Alternate paths

Control flow

Business Item

Annotation

8 - 18

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

8 - 19

Business Use Cases in Rational Software Architect

Business Processes
In Rational Software Architect, a business process maps to:
A use case and realization (black box) view An activity diagram (white box) view

8 - 20

Mapping Business Items to Classes

Business Item in WebSphere Business Modeler

8 - 21

Business Entities in Rational Software Architect

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

Module 9 : Dexis Case with UML

Cas Dexis: Octroi de prts par un organisme bancaire

Enonc La banque Dexis souhaite rorganiser ses activits lies l'octroi de prts afin de rendre celles-ci plus performantes et plus quitables. La direction de la banque espre que, suite cette rorganisation, les demandes de prts augmenteront au minimum de 0,75% lanne suivante. Elle espre galement attirer de nouveaux clients et renforcer son image. Le client dune agence de la banque Dexis doit soumettre sa demande de prt au service client en indiquant le montant qu'il souhaite emprunter, la dure, le motif du prt ainsi que des renseignements gnraux tels que son nom, son adresse et son revenu mensuel. Il sattend ce que le service de Dexis soit professionnel et de qualit. Le service client de l'agence constitue un dossier avec les diffrents renseignements et le transmet au service crdit du sige de la banque pour des objectifs de centralisation des dossiers de prt. Les clients souhaitent que cette transmission se fasse de manire la plus confidentielle qui soit. Un mme dossier peut traiter de plusieurs prts condition que le client soit le mme pour tous les prts du dossier. Le service crdit dcide de lacceptation ou du refus des prts. Il examine chaque dossier en dtail, en vrifie les informations et dcide sur base du revenu mensuel et du motif du prt de refuser la demande ou de l'tudier de faon plus approfondie. Le service crdit prend sa dcision sur base de normes strictement dictes par le service juridique du sige de la banque. En cas de problme, le prpos peut demander lavis du service juridique de manire motiver correctement sa dcision. Le service crdit peut aussi senqurir auprs du service placements des avoirs du client condition que le service juridique de la banque ne soit pas oppos ce transfert dinformation. Dans le cas dune tude plus approfondie, le service crdit met une demande de renseignements auprs du service d'information. Ces renseignements portent d'une part sur le pass du client loccasion du remboursement d'ventuels prts antrieurs et d'autre part sur l'identit du client, son revenu mensuel, ... Contrairement au service crdit, le service dinformation a une libert totale pour la ralisation de ses objectifs condition toutefois dobserver les lois sur la protection des donnes et de la vie prive. Le service crdit sattend ce que les renseignements demands soient les plus exacts et objectifs possible. Il vrifie galement que le dossier est bien transmis dans son entiret. Dans l'attente de ces informations, le service crdit tablit un premier plan de financement, comportant: le taux appliquer, le montant et la dure du prt. Quand il a reu la rponse du service d'information, il peut soit refuser la demande soit formuler une ou plusieurs propositions prsenter au client. Les propositions sont jointes la demande qui retourne l'agence. A la rception 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 rserve de modifications (modification de la dure, diminution du montant emprunt, ...). Dans ce dernier cas, la direction de lagence tablit avec le client une nouvelle proposition qui tient compte des changements demands.

9-2

Une proposition de prt accepte par le client doit encore tre approuve par la direction de la banque. Celle-ci s'occupe des dossiers de prt en fin de semaine ou lorsqu'elle en a au moins 20 en attente. Lapprobation ou le refus de la direction se concrtise par une note (accord ou refus) reprenant la date courante, le numro du dossier et la raison (en cas de refus). Ensuite les dossiers approuvs retournent en agence o ils donnent lieu l'tablissement du contrat de prt. En cas de refus, le client peut sadresser directement au service juridique de Dexis et demander un complment dinformation ou une enqute interne sil estime avoir t ls. Si la dcision ne lui convient toujours pas, il peut aussi sadresser lombudsman attach la direction de Dexis. On connat le nom, l'adresse, le salaire mensuel d'un client et les prts qu'il a dj ventuellement obtenus auprs de la banque Dexis ou d'une autre institution financire ainsi que, pour chacun de ceux-ci, la faon dont il a rembours (rgulier, tardif, mauvais). On connat galement les demandes de prt qu'un client a dj ventuellement mises auprs de la banque Dexis et, si elles ont t acceptes, les diffrentes propositions auxquelles elles ont donn lieu. Une demande de prt comporte les renseignements suivants : montant demand, dure demande, date d'introduction de la demande et motif du prt, taux souhait, plan de remboursement souhait. A condition que le client ou le notaire ne sy opposent pas, les donnes du notaire sont aussi utiles ltablissement du dossier. Le client peut aussi rfrencer certaines personnes en vue de garantie. La direction de lagence seconde du service dinformation vrifie ces informations pour le service crdit charg daccepter ou de refuser le prt. Pour une institution financire, on connat son nom, son type (banque, organisme priv, organisme public) et les diffrents prts contracts par les clients de la banque Dexis auprs de cette institution. Pour chaque prt, on connat son numro, son montant, sa dure, le client, l'organisme auprs duquel il a t contract (si ce nest pas la banque Dexis), le type d'chance (mensuelle, trimestrielle, annuelle), les dates de dbut et de fin de remboursement, le taux d'intrt et le montant rembourser (montant prt + intrts). Pour des raisons lgales, le remboursement doit faire lobjet dun dossier de remboursement spar du dossier de prt. Il contient toutes les informations propres au type de remboursement et rpertorie les problmes de paiements, les intrts de retard, les lettres de rappel, Dans la base de donnes, on diffrencie les personnes qui sont ou non employs de Dexis. Une distinction est galement faite entre types de clients (particuliers, indpendants, ). Une proposition de prt est caractrise par sa date, la dure et le montant du prt propos, le taux d'intrt. On enregistre quotidiennement le taux d'escompte. Le taux d'intrt est dtermin par la banque Dexis en fonction du motif, du montant et de la dure du prt, ainsi que du taux d'escompte. Les valeurs des diffrentes informations relatives un prt sont ncessairement identiques aux informations correspondantes de la proposition qui lui a donn lieu (si elle existe).

9-3

Business Use-Case Diagram

9-4

Business Activity Diagram

9-5

Business Activity Diagram

9-6

Business Activity Diagram

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

Communication Diagram

9 - 16

Sequence Diagram

9 - 17

Communication Diagram

9 - 18

Sequence Diagram

9 - 19

Communication Diagram

9 - 20

State Machine Diagram

9 - 21

State Machine Diagram

9 - 22

Component Diagram

9 - 23

Deployment Diagram

9 - 24

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

Module 10 : CARSID Case with RUP

Classical Waterfall Development

Achievement of sequential activities Based on too strong assumptions :
Requirements are all knowable in advance Requirements have no high risk implications Enough calendar time

Requirements analysis Analysis and Design Implementation Deployment Test

10 - 2

Iterative 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
Iteration 1
R AD I D T

Iteration 2
R AD I D T

Iteration 3
R AD I D T

T I M E
10 - 3

Iterative Development Produces a Release

Requirements Business Modeling Test Anchor Point Milestones Project Management Deployment Implementation Analysis & Design

Each iteration results in an executable release

10 - 4

RUP / UML

Standards UML: 9 models UML RUP: software project management RUP Web Application Design Support Data base design ISO i.e.

12207 : Software Life-cycle processes 9126: Software Quality Characteristics & Metrics 9001 : Quality Management Systems,
10 - 5

RUP : an Iterative Development Process

Anchor Point Milestones

10 - 6

Case Study : CARSIDs Coking Plant

CARSID (Carolo-Sidrurgie) Duferco - Usinor (60/40) Ex-Cockerill Sambre in Marcinelle-Marchienne Steel, coke, sinter charge, cast iron, slabs. CARSID Database re-organization Migration, integration, new information system strategy Migration integration Knowledge management, continuation, training IT project management and methodology Standardized/open modelling techniques (UML/RUP) UML/RUP Web Online, Intranet and E-Commerce exploitation

10 - 7

Workflow
Agglomration Agglom Marcinelle Marchienne Haut-fourneau Haut4 Four lectrique Cokerie

Marcinelle Marcinelle Acirie Aci Mtallurgie de poche

Marcinelle Marcinelle Coules continues Coul brames Marcinelle

10 - 8

Schema

10 - 9

Coking ovens and Tools

C4

LC3

TOUR EXTINCTION

Rserve C3 LC1

1GC2 Rserve

1GC1 E1

2GC2

2GC1 rserve

C1 New

2000 D1

C2

TOUR DE STOCKAGE CHARBON

K
D3

E2

D2 Rserve

10 - 10

Coking Plant

10 - 11

Loading

10 - 12

Deloading

10 - 13

Cooling

10 - 14

DECHARGEMENT FADS MEYER

TP1 TP2 TP3 TP4 TP5

BROYAGE MELANGE

Mlange broy destin aux fours Stocks de charbons

TP6 TP7

Mlange broyer

Silos de stockage des charbons

DOSAGE CHARBONS (MELANGE)

TP8

MAGASIN ATELIERS E.L.M.

Mlange broy destin aux fours

HALL ANCIEN T900

COPPEE I COPPEE II
FOURS

TOUR DE STOCKAGE

KOPPERS DIDIER
FOURS

BASCULE

BUREAUX

UML / waterfall : Use Case Diagram

Requirements Analysis
Tour__Charbon
(f rom Logical View)

Four
(f rom Logical View)

quipe prparation

mlange Enfourneuse
(f rom Logical View)

quipe rglage

approvisionnement tour charbon

rglage

inversion mesurage t

chargement enfourneuse

enfournement

<<extend>> Guide_Coke
(f rom Logical View)

<<extend>>

dfournement transfert charbon silo

<<extend>>

cuisson

rception fads quipe FADS

refroidissement

Coking

rception charbon rception rserve Coke_Car

(f rom Logical View)

criblage du coke

quipe four

10 - 16

UML / waterfall : Activity Diagram

Requirements Analysis
stock_charbon : Stock_Charbon dtecteur : Detecteur_Overband bande : Bande_Transporteuse silo mag : Silo_Magasin silo dos : Silo_Doseur bande : Bande_Broyeur broyeur : Broyeur tour : Tour__Charbon enfourneuse : Enfo urneuse fou r : Fou r dfourneuse : Dfourneuse guide : Guide_Coke car : Co ke_Car tour : Tour_Extinction aire : Aire_a_Coke cribleur : Criblage

(transferts dbuts) transporter le brut (Brut en silo) rceptionner le brut transfrer au doseur (remplissage du doseur) (remplissage du magasin) stocker le brut

rception du brut

contrler le charbo n

(mtaux retirs)

(mlange non disponible) broyer le mlange de brut

doser le m lange

(mla nge d ispo nible) transporter le mlange

(arrive d'un train, bateau ou camion) (mlang, broy et transport)

rceptionner et stocker la pte (tour charge e n pte) approvisionner l'enfourneuse (enfourneuse pleine) recharger galiser la charge du four

(enfourneuse aligne et ouverte) fournir la pte au four (cuisson termine) cuire la pte

diri ge r la charge

vider le four (fou r rempli et fe rm)

pousser la charge de saumon

prendre la temprature et le profil

rceptionner le saumon

( coke car align la tour d'extinction ) teindre le transporter au saum on refroidissement (charge d 'eau dverse)

(coke car charg de coke)

(temps de refroidissement coul) laisser se refroidir la charge

transporter au quai d'attente

(coke car a lign l'a ire coke) (sau mon teint) arroser (sau mon teint)

(saumon non teint)

transporter et dversr la charge au criblage

cribler le coke ( coke cribl )

(coke car align au criblage)

Cooking Process

10 - 17

UML / waterfall : Activity Diagramme

( coke car align la tour d'extinction ) transporter au refroidissement (charge d'eau dverse) teindre le saumon (temps de refroidissement coul) laisser se refroidir la charge

transporter au quai d'attente

(coke car align l'aire coke) (saumon teint) arroser (saumon teint) (saumon non teint)

transporter et dversr la charge au criblage

cribler le coke (coke car align au criblage) ( coke cribl )

Cooling Process
10 - 18

UML / waterfall : Class Diagram

Planning_d

Analysis
Sau mo n prof il : pr of il t em pr ature ( haut ) : Integer t em pr ature ( milieu) : In tege r t em pr ature ( bas) : In tege r 0. .n 0..n 0..1 0..4 0..4 0..n

def ournement_en_cours : Def ournement EQ f our 1 0..4 0..4 0..4 prpare 0..n 0..n 0..n def ournement_suiv ant() optimiser()

1 0..n Def ournement date & heure planif ies : Date date & heure ef f ectiv es : Date f orce : Force de df ournement f our : Four coke_car : Coke car guide_coke : Guide coke def ourneuse : Df ourneuse cause_non_respect_timing : String pression : Integer encoder_cause() 0..n 0..n correspo

0..4

0..n

correspond

correspond

0..3 0..1 Tour _E xti nction Niv eau_eau : Integer dv erse_charge() est_libre() reserv oir_plein() teint saumon 0..1 0..2 0..2 0. .2 apporte saumon 0..1 0..1 0..2 C oke_Car puissance : Integer alimentation : Variant est-v ide() rceptionner_mp() aligner_tour() aligner_cribleur() aligner_aire() dev erser_coke() 0. .1 1 Df ourneuse nom : String puissance : Integer alimentation : Variant planning : Planning_d df ournement : Def ournement ouv rir_f our() df ourner() f ermer_f our() cherche_def ournement() v alidation_def ournement() ouv rir_trappe() galiser_contenu_f our() f ermer_trappe() 1

0..4 0..1

Unloading
10 - 19
Positionable

guide coke mesure

UML / waterfall : Sequence / Collaboration

Design
: quipe four 1: aligner(Four) 2: aligner(Four) 3: ouvrir( ) 4: ouvrir_bouches( ) 5: ouvrir_trappe(Fo... 6: remplir_four(Pte__coke) 7: galiser_contenu_four( ) : Enfourneuse : Dfourneuse : Four

: Dfourneuse

8: transfrer_saumon(Saumon) 9: prendre_profil(Saumon)

1: aligner(Four)

5: ouv rir_four( ) 7: dfourner( ) 12: fermer_four( ) 2: aligner(Four) : Guide_Coke

: quipe four

4: ouvrir( ) 6: ouv rir_porte( )

8: fermer( ) 9: fermer_bouches( ) 10: fermer_trappe( )

3: aligner(Four)

13: fermer_porte( ) 10: rceptionner_mp(Saumon)

: Coke_Car 11: fermer( )

: Four

Loading
10 - 20

Unloading

UML / waterfall : Statecharts

Design
actif-1300C enfourneus e.remplir_four() attente enfournement dfourneuse.fermer_four() and guide_coke.fermer_porte() est enfourn attente defournement dfourneuse.ouvrir_trappe() attente galisation dfourneuse.galiser_contenu_four() est galis guide_coke. ouvrir_porte()

dfourneuse.dfourner() dfourn

dfourneuse.ouvrir_four() att ente ouvert ure porte

dfourneuse.fermer_trappe()

cuisson_termine()

cuisson

activer()

dsactiver() inactif-700C

dmarrage

Oven
10 - 21

CARSID : RUP/Project Management

Inception
Business Modeling

Elaboration

Construction

Transition

Requirements

(A) (B) (D) (C) (E) (F) (K) (L) (G) (M) (H) (N) (I) (O) (J) (Q)

Analysis & Design

Implementation

Test

Deployment

(P) (T)
Iteration preliminary Elab #1

(R) (S) (T)

Project management

(T)
Elab #2
10 - 22

(T)
Const #1 Const #2

Tran #1

Iterations

MS Project RUP / Project Manager

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

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

(T) Project Management

10 - 23

Business Analyst (UC Diag)

<<support>>

Coke de qualit Management

Equipe rglage

Equipe Four

Cribler coke

Coke

Inversion Grer la cokerie

Guide coke, coke car et dfourneuse positionns Cuisson

Guide coke

Saumon de coke cuit

(A) Iteration 1 : Elaboration Business Modeling

<<support>>

Obtenir rapidement de bons rapports d'analyse des charbons

<<support>>

Dfourneuse Guider coke

<<include>>

<<support>>

Dfournement Four
<<support>>

Enfourneuse positionne Ingnieur de production

<<support>>

Coke car

Collecter des informations de production de qualit Grer la production

<<support>> <<support>>

Enfournement

Enfourneuse

Eteindre coke

Fournir des informations de production de qualit

Optimiser le planning des enfournements - dfournements des pauses

Equipe prparation Chargement enfourneuse

Rception charbon

Mlanger charbon Tour d'extinction

Amliorer les communications entre les travailleurs

Amliorer l'extraction des donnes

Amliorer l'analyse des donnes de pause

Equipe FADS

Tour charbon

10 - 24

Business/Syst. Analyst (UC Diag)

Broyeuse Equipe mlange Enfourneuse EnfourneuseE3

(B) Iteration 2 : Elaboration Business Modeling

<<extend>> EnfourneuseE1

Mlanger charbon

Enfournement <<extend>> <<extend>>

Encoder temperature c arneaux

Cuisson

Four <<extend>> <<extend>>

quipe prparation Tour__Charbon
(f rom Logical View)

<<extend>>

Four
(f rom Logical View)

Defouneus e

Defournement

Creer planning defournement

mlange Enfourneuse
(f rom Logical View)

quipe rglage

approvisionnement tour charbon

Guide Coke <<include>>

<<include>>

<<include>>

rglage

inversion mesurage t

chargement enfourneuse

enfournement

Rechercher Information

Utiliser intranet

Encoder Cahier Electronique

Guide_Coke
(f rom Logical View)

<<extend>>

<<extend>>

<<extend>> dfournement transfert charbon silo cuisson

rception fads

refroidissement

Management

Chercheur d'informations

Utilisateur

Equipe controle

quipe FADS rception charbon rception rserve Coke_Car

(f rom Logical View)

criblage du coke

quipe four

Ingenieurs de production

Service informatique

Contremaitre

Equipe reglage

10 - 25

(C) Iteration 3 : Elaboration Requirements Analysis

Business Process Analyst (Act Diag)

(D) Iteration 1 : Inception Business Modeling (E) Iteration 2 : Elaboration Requirements

stock_charbon : St ock_Charbon

dt ecteur : Det ecteur_Ov erband

bande : Bande_Transporteuse

silo m ag : Silo_M agasin

silo dos : Silo_D oseur

bande : B ande_B royeur

broyeur : Broyeur

tour : Tour__C harbon

enfourneus e : Enfo urneuse

f ou r : Fou r

dfourneuse : D fourneuse

guide : Guide_C oke

c ar : C o ke_ Car

tour : Tour_Extinction

aire : Aire_a_Coke

cribleur : Criblage

(trans ferts db ut s ) tran s p orte r le b rut (Brut en s ilo) r ce ptionn er le bru t tra ns frer au do s eu r (rem plis s age d u d os e ur) (rem plis s a ge du m a ga s in ) s tocker le b rut

Tour charbon

Equip e enfour nement

Enfourneuse

Dfourneuse

Ba se de don nes

Contrematre

rception d u bru t

co ntr ler le ch a rbo n

(m ta ux re tir s )

(m lang e n on dis po nible ) b royer le m lan ge de bru t

Mlange dans la tour a charbon

dos er le m lan ge

( m la nge d ispo nible ) tra ns p orter le m la n ge

(arriv e d 'u n train, batea u o u cam io n) (m lan g, broy e t tran s po rt )

rception ne r et s tocker la p te (tou r ch ar g e e n pte ) app rovis io nne r l'e nfo urn eus e (en fou rne us e p leine) recha rge r ga lis er la ch arg e d u fou r

Chargement de l'enfourneuse

Ouverture des mamelles de remplissage

Positionnement au-dessus du four

(enfourneu s e align e et ou ve rte ) fou rnir la p te a u four (cuis s o n term in e) cu ire la p te

d iri ge r la char ge

Alignement IPOVECO
rception ne r le s au m on

Repalage

vid er le fou r (fou r re m pli e t fe rm )

pou s s e r la cha rge de s a um on

prend re la tem p ratu re e t le p rofil

( coke car align la to ur d'e xtin ction ) tein dre le trans po rter au s au m on refroidis s em en t (ch arge d 'ea u dver s e)

Remplissage du four
(tem ps de refroid is s em en t co ul ) lais s e r s e re froidir la cha rge

(coke ca r cha rg de co ke)

trans po rter au q ua i d 'atten te

( co ke car a lign l'a ir e co ke ) (sa u mo n teint) arro s e r ( sau m on tein t)

(s a um on non teint)

tran s po rte r et d vers r la ch arg e au crib la ge

cribler le co ke ( coke cribl )

(coke car align a u crib lag e)

Scell des mamelles

Enregistrement des donnes relatives l'enfournement Vali der l'enfournement

G u id e co ke

Dfo u rn eu se

Co ke car

F o u r co ke

Co th erm

Co n trematre

F in de la c uis s on

E quipe m lange

Tapi s ro ula nt

Broye us e

La bora toire
Alignem ent du guide c ok e Alignem ent de la df ourneus e Alignem ent du c ok e c ar

Mise en si lo du c harbo n Calcu ler l es mlange s Racler les charbons

Mis e en plac e de l'auge m obile du co k e c ar

Ouv erture des por tes

Mlanger

Analyser mlange charbon

Pous s e le c ok e dans le c ok e c ar R elev de la tem prature, de la puis s anc e et du prof il c ok e

Transporter le ml ange

Broyer

Rapporter les rsultats de l'anal yse dans l'intranet

F erm eture des portes

F our v ide

Val id er le df ournem ent

10 - 26

System Analyst (Class Diag.)

Chariot_Racleur Localisation : string transfert() stop_transfert() est_actif() 1 Detecteur_O verband detection_dechirure() arrter() est_actif() 1 T ransporteur Localisation : String est_actif() dmarrer() arrter() 0..10 Bande_T ransporteuse_pate 0..10 T our__Charbon Niveau : Integer transfert_charbon() approvisionnement() mlange() 0..1 0..1 0..1 Enfourneuse nom : String niveau : Integer puissance : Integer alimentation : Variant 0..n 0..* aligner_tour() remplir_four() ouvrir_enfourneuse() fermer_enfourneuse() ouvrir_bouches() fermer_bouches() 0..2 Contient dirige entre 0..n 0..1 0..1 transfere transfre 1..10 1..* approvisionne enfourneuse--mesure

Stock_Charbon T ype : String Provenance : String Date : Date transfert() livraison() 0..n

transporte 1..n 0..1 0..1

1 1Bande_Transporteuse dmarrer() arrter() est_actif() 0..1 0..1 dplace 0..n

stocke 1

Silo_Magasin capacit

melange 0..n 1..n

Silo_Doseur capacit

0..1

Stocke

0..* 1 Brut 0..* F ADS Reserve localisation : String

contrle contient 0..*

Silo Niveau : Integer Humidite : Double Localisation : String Capacit : Integer mlange() remplir_silo() 0..n

Broyeur dmarrer() arrter() est_actif()

1 broie 0..1 0..n

0..n Pte__coke 0..*

remplit s'occupe

0..n

enfournement quantit : Double date et heure planife : Date date et heure effective : Date contient 0..2 0..2 EQ prep

planning_e 1 1..*

0..*

controle

0..n F our numro : Integer respecte_planning : Boolean T emperature : Integer capacit : Integer

0..1 0..1 EQ.F ADS 0..1

0..2 dirige 0..n

rpare

0..n 0..n

EQ maon rparer-four() 0..1

porte_entre_ouverte() porte_sortie_ouverte() est_vide() est_enfourn() est_galis() cuisson_termine() trappe_ouverte() ouvrir() fermer() activer() dsactiver() temprature_estim() 1

0..50

Batterie Nom : {Coppee1, Coppee2, Koppers, Didier} T emperature_globale : Integer Heure_inversion_suivante : Date nb_fours : Integer temps cuisson : Integer nb_carneau : Integer qt_enfournable : Integer 1

(F) Iteration 1 : Elaboration Requirements (G) Iteration 2 : Construction Analysis

personne nom : String prnom : String ge : Integer titre : String

1..n

Equipe_de_travail rotation : Integer nombre personne : Integer contrematre : personne horaire : Date

contrle

1..n Piedroit Numero : Integer sens_inversion : Boolean inversion() check_pression() check_temprature() EQ reglage 1 compose 0..1 1..n 0..n mesure temprature : Double temps : Date Carneau Numero : Integer T emperature : Integer est_en_chauffe()

matire_premire proprit quantit : Integer 0..4 EQ four 0..4 0..4 1 0..4 prpare 0..n 0..n 0..n 0..n 1 0..n Defournement date & heure planifies : Date date & heure effectives : Date force : F orce de dfournement four : F our coke_car : Coke car guide_coke : G uide coke defourneuse : Dfourneuse cause_non_respect_timing : String pression : Integer encoder_cause() 0..n 0..n coke temprature : Integer cribl() 0..n 0..n correspond correspond 1 correspond 0..n 0..4 correspond Planning_d defournement_en_cours : Defournement defournement_suivant() optimiser() 1

Saumon profil : profil temprature (haut) : Integer temprature (milieu) : Integer temprature (bas) : Integer 0..n 0..n

0..4 0..4 0..4 0..1

0..3 0..1 0..1 Criblage cribler() arrter() est_libre() 0..1 0..1 0..2 Coke_Car puissance : Integer alimentation : Variant 0..2 0..2 0..2 apporte coke 0..1 Aire_a_Coke temps_attente : Date attente_refroisissement() arrosage() est_libre() 0..1 apporte saumon est-vide() rceptionner_mp() aligner_tour() aligner_cribleur() aligner_aire() deverser_coke() 0..1 1 Dfourneuse nom : String puissance : Integer alimentation : Variant planning : Planning_d dfournement : Defournement ouvrir_four() dfourner() fermer_four() cherche_defournement() validation_defournement() ouvrir_trappe() galiser_contenu_four() fermer_trappe() 1

0..4 0..1

G uide_Coke puissance : Integer alimentation : Variant transfrer_saumon() ouvrir_porte() fermer_porte() prendre_t() thaut() tmilieu() tbas() prendre_profil()

0..1

T our_Extinction Niveau_eau : Integer dverse_charge() est_libre() reservoir_plein() teint saumon 0..1

0..1

0..1

guide coke mesure

Auge_Mobile En_place : Boolean

Positionable position() aligner() est_libre() align_sur()

Pays 1 cod_pay : I nt eger pay : St r ng i

Anal seC bon y har Q uant t e : Long i

El m ent e N om : St r ng i 0. . n 0. . n

0. . n

Anal seC y oke Q uant t e : Long i G r anul m et r e o i I nt er val : St r ng i N om : St r ng i

M sgC m uni at on om c i Aut eur : St r ng i D ebut Af f chage : D e h_D i at D nA f chage : D e h_Fi f i at C m ent ai e : St r ng om r i R esponse : St r ng i

Local e t i cod oc : . . . l oc : St r ng l i 1 C nt l i e ( f r om C oncept ual odel ck) M P 0. . * t er s i cod t e : . . . i nom t e : . . . i adr t e : . . . i or i : St r ng i 1 0. . * C m ande om num com : I nt . . . ent _sr t : Bool an e 1 1. . * 0. . n

1 1 O r gen i

A yseM el nge nal a Q uant t e : Long i

0. . 1

M essageR et e ej I d_M sg : I nt eger D eTr ai em ent M sg : D e at t at N er oEr r eur : I nt eger um D escr pt onE r eur : S r ng i i r t i Em et t eur M sg : St r ng i N er oM sg : I nt eger um b e l 1 Li el M sgr : St : ng r ng Sour ceEr eur r i St i

M essageTr aceC onol gi u hr o q eD a at D eTr ai em ent M sg : D e at t at Em et t eur M sg : D e at N er oM sg : D e um at N er oSec : D e um at D at a : D e h_D at Ent et eM sg : St r ng i D h_Pause : D e at 0. * D . h_Jour : D e at D h_M oi : D e s at TC st eS eTem pPyr om et r e xLi er i I d_Ser e : I nt eger i TypeD az : St r ng eG i PC : I nt eger I D : D e h at Pyr om et r eur : St r ng i R eur : St r ng egl i C m ent ai e : St r ng om r i Val e : Bool an d i e TC xSer eTem pPyr om et r e i N C : I nt eger um x Tem per at ur e : I nt eger 0. . * 1 0. . * 0. . * 1 TcxTypeD esur e eM I d_TypeD esur e : I nt eger eM Li el : St r ng b e l i R ecapJour C odui oPr t D hJour : D e at Vol m eR u es2G oudr on : I nt eger Vol m eR u es3G oudr on : I nt eger Vol m eR u es4G oudr on : I nt eger Vol m eR u es5G oudr on : I nt eger Vol m eR u es6G oudr on : I nt eger Vol m eR u es7G oudr on : I nt eger Vol m eR u es8G oudr on : I nt eger Vol m eR u es9G oudr on : I nt eger Vol m eR u es10G oudr on : I nt eger C eur Fuel er sC r al vant : I nt eger pt V ent A C eur Fuel er sC r al pr es : I nt eger pt V ent A Li r ageFuel er sC r al : I nt eger t V ent Pl ce a N e : St r ng am i 1 0. . n

D acer epl D epar t G oud : D e h_D at R our EauC on : B ean et am i ool Type : St r ng i Fi m eEnt r eeFuel : St r ng r i H eur Avant Ent r eeFuel : Si gl t n e H eur Apr esEnt r eeFuel : Si gl t n e N esEnt r eeFuel : Si gl oR n e Li r ageEnt r eeFuel : S gl t n e i H eEnt r ee : St r ng eur i

R ecapPauseC odui oPr t D hPause : D e at Ext r act eur N d : Si gl or n e Ext r act eur Sud : S gl n e i Vi esseN d : Si gl t or n e Vi esseS : Si gl t ud n e D t N d : Si gl ebi or n e D t Sud : Si gl ebi n e Tem per at ur eVol t eN d : Si gl u or n e Tem per at ur eVol t eSud : Si gl u n e Am per ageN d : S gl or n e i Am per ageSud : Si gl n e R at onN d : St r ng egul i or i R at onSud : St r ng egul i i VanneR appol N d : St r ng d or i VanneR appol Sud : St r ng d i Pr essi nH eEnt r eeN d : Si gl o ui l or n e Pr essi nH eEnt r eeS : Si gl o ui l ud n e Pr essi nH eSor t eN d : Si gl o ui l i or n e Pr essi nH eSor t eSud : Si gl o ui l i n e Vi r at onH zont al N d : Si gl b i or i e or n e Vi r at onH zont al S : Si gl b i or i e ud n e Vi r at onVer t cal N d : Si gl b i i e or n e Vi r at onVer t cal Sud : Si gl b i i e n e Tem per at ur eExt er eur eN d : Si gl i or n e Tem per at ur eExt er eur eSud : Si gl i n e C ondensat onD t : Si gl i ebi n e C ondensat onAnal se : Si gl i y n e LavageD t : Si gl ebi n e LavageA yse : Si gl nal n e C ebi : Si gl SFD t n e C SFAnal se : Si gl y n e Bi ogi ueD t : Si gl ol q ebi n e Bi ogui ueAnal se : Si gl ol q y n e Vent ur D t : Si gl i ebi n e Vent ur Tem per at ur e : Si gl i n e Vent ur P : Si gl ih n e Br gadi r : St r ng i e i O per at eur : St r ng i O per at eur G azom et r e : St r ng i I t ner ant C odui : St r ng i opr t i I t ner ant Bi G azom et r e : St r ng i o i C haguer G our don : St r ng i H sQ uot a : St r ng or i Tem pSor t i C 1 : Si gl e TH n e Tem pSor t i C 2 : Si gl e TH n e Tem pSor t i C 3 : Si gl e TH n e Tem pSor t i C 4 : Si gl e TH n e Tem pSor t eEG R : Si gl i 1 n e Tem pSor t eEG R : Si gl i 2 n e Tem pSor t eEG R : Si gl i 4 n e Tem pSor t eEG R : Si gl i 3 n e Tem pEnt r eeLaveur 5N d : Si gl or n e Tem pEnt r eeLaveur 5Sud : Si gl n e Tem pEnt r eeLaveur 1N d : Si gl or n e Tem pEnt r eeLaveur 1Sud : Si gl n e Pr essi nEt D t Vapeur : St r ng o ebi i N eauR v i es500 : Si gl n e N eauR v i esB500 : Si gl n e N eauR v i es1000 : Si gl n e N eauR v i es800 : Si gl n e N eauR v i es6514 : Si gl n e Post eEm et t eur : St r ng i D ect eur C : St r ng et O i C m ent ai e : St r ng om r i Si nat ur eBr gadi r : St r ng g i e i C m ent ai eO per at eur : St r ng om r i Si nat ur eO per at eur Techni ue* : St r ng g q i Vol m eR u esFuel 509 : Si gl 6 n e H eur R aut esFuel 509 : Si gl 6 n e Vol m eR u esFuel 508 : Si gl 6 n e H eur R aut esFuel 508 : Si gl 6 n e Vol m eR u esFuel 511A : Si gl 6 n e H eur R aut esFuel 511A : Si gl 6 n e Vol m eR u esFuel 511B : Si gl 6 n e H eur R aut esFuel 511B : Si gl 6 n e Laveur 1N dD t : Si gl or ebi n e Laveur 1N dPassage : Si gl or n e Laveur 1SudD t : Si gl ebi n e Laveur 1SudPassage : Si gl n e Per t eFuel : Si gl n e H eur SoudeAvant : Si gl aut n e H eur SoudeApr es : Si gl aut n e C onsom m at onSoude : Si gl i n e

Post pst _num : I nt eger dat _pst : D e at Fam _ar t ce il f am _ar t : St r ng i b_f am : St r ng i l i or i : St r ng i

0. . n

0. . n C bon har N ber : I nt eger um N om : St r ng i M el nge a N e o : I nt ge u r m e r Sw ng d C t M ax : Lo g e iI n o l n n Sw ng d D ax : L o g e iI n M l l i n N : S tn g o m i r

0. . n G r anC oke Q uant t e : I nt eger i 0. . * 0. . *

0. . *

0. . * Four ni seur s 1 ( f r om C oncept ual odel ck) M P 0. . * 0. . *

G r anM el nge a Q uant t e : I nt eger i concer ne Test 2 : St . . . Bascul e 0. . n 1 1 0. . * Li r ai on v s cod v : I nt . . i l b_l : St r ng i v l i i i 1 or i : St r ng 0. . n Badge Ar t ce il cod_ar t : I nt eger cod_env : St r ng i b_ar t : St r ng i l i bel : St r ng i e l l i or i : S r ng t i 0. . * 0. . * 0. . n SubM vt C bon har 0. 1 . Envoi 0. . 1 N er o : I nt eger um N er o : I nt eger um Poi s : Long d D eTi e : D e at m at 0. . 1 1 C poseM el nge om a Q uant t e : I nt eger i 1 1 0. . n 1. . * 0. . n M vt C bon har N er o : I nt eger um Poi s : Long d D eTi e : D e at m at 0. . n 0. . n 1 0. . n 0. . n 0. . n M vt M el nge a N er o : I nt eger um Podi : Long s D eTi e : D e at m at 1 0. . 1 0. . n 0. . n M vt C oke N er o : I nt eger um Poi s : Long d D eTi e : D e at m at R our n : Bool an et e

Sal s e Poi s : Long d D eTi e : D e at m at

1 1 Four I d_Four : I nt eger 0. . * 1 1. . 2

M sgG r oupe I d_G r oupM sg : I nt eger Li el M sg : St r ng b e l i TypeM sg : St r ng i

Pi dr oi e t I d_Pdt : I nt eger Li el : St r ng b e l i

Pdef D Pour D H ebug D ai t enant : D e hM n at D hAvant : D e at C gneTem psC sson onsi ui I d_C gne : I nt eger onsi D ebut C h_D hangem ent : D e at C onsTpsC s_Kopper sD er : I nt eger ui di i C onsTpsC s_C ui oppee : I nt eger

0. . *

0. . *

C onC odui am i oPr t N aque : St r ng oPl i

Pesee num : I nt . . . D eTi e : . . . at m pesee1 : I . . . 0. . * pesee2 : I . . . pes val : B. . . pes ann : . . . r em : St r ng i 0 .1 r em sys : . . . st at us : S. . . b pr e : St . . . i l 0. . * cod pr e : . . . 0. . *

i 1 bas d : I n. . . bas : St r ng i

0. . * 1 Bat t er e i I d_Bat t er e : I nt eger i Li el : St r ng b e l i I d_Pdt D ebut : I nt eger 1 N om : St r ng i N Four D : I nt eger um eb N Four : I nt eger br N Pdt : S r ng br t i 1

0. . n 1 1 1 1

0. . * 0. . * Pdel st eH ePour M odel Li ht Li eur e g I d_Pr ogr : I nt eger H eFour : D e eur at P ef Par am et r e D 0. . * Pl nni gEnt r et en a n i 0. . * D ebut : D e h_D at D eeE nut e : I nt eger ur nM i I d : I nt eger D eD ni r eM odi : D e at er e f at C m ent ai e : St r ng om r i D h_PauseEnC s : D e our at TpsC ssonC ui oppee : I nt eger TpsC ssonKopper s : I nt eger ui D aEnt r eD our nEt Enf our n : I nt eger el i ef E t M axTpsC ssonC car ui oppee : I nt eger E t M axTpsC ssonKopper s : I nt eger car ui E t Sur Pr ogr Tol r eC car e oppee : I nt eger E t Sur Pr ogr Tol r eKopper s : I nt eger car e D aul D aEnt r eD Et Enf : I nt eger ef t el i ef M odi D achi eAut or see : I nt eger f hM n i D aEnSecondeD ef r eshAut oI nt er f ace : I nt eger el i uR Ti eO ut Execut eM odel : I nt eger m e N H eAvant PauseC ant eAVi ual er : I nt eger br eur our s s i N H eApr esPauseC ant eAVi ual er : I nt eger br eur our s s i P assw dO pt on : St r ng or i i A m at onVi eo : I nt eger ni i d M _PV_Enabl d : I nt eger e M _PV_kdpapH : I nt eger S E r et enH eM n : I nt eger nt i eur i E r et enH eM ax : I nt eger nt i eur E r et enD eeM n : I nt eger nt i ur i E r et enD eeM ax : I nt eger nt i ur E r et enPasM n : I nt eger nt i i R ecapPauseFour D hPause : D e at N Aj st eur : St r ng om u i C m ent ai eA st eur : S r ng om r u j t i Si nat ur eAj st eur : St r ng g u i N El ct r can : St r ng om e i i i C m ent ai eE ct r can : St r ng om r e ii l i Si nat ur eEl ct r can : St r ng g e ii i N C r em ai r e : St r ng om ont t i Assi t ant C r em ai r e : St r ng s ont t i C m ent ai eC r em ai r e : St r ng om r ont t i Si nat ur eC r em ai r e : St r ng g ont t i N eD our nem ent C br ef oppee : Si gl n e N eD our nam ent Kopper s : Si gl br ef n e N eD our nam ent D er : Si gl br ef di i n e Et at C ssonC ui oppee : St r ng i Et at C ssonKopper s : St r ng ui i Et at C ssonD er : St r ng ui di i i Pl t eauC a oppeeN t oyeC eC et ot oke : St r ng i Pl t eauKopper sN t oyeC eC a et ot oke : St r ng i Pl t eauD er N t oyeC eC a di et i ot oke : St r ng i Pl t eauC a oppeeN t oyeC eM achi e : St r ng et ot n i Pl t eauKopper sN t oyeC eM achi e : St r ng a et ot n i Pl t eauD er N t oyeC eM achi e : St r ng a di et i ot n i TpsE nct onEnSeconde : I nt eger xt i i TpsE gout t ageE nSeconde : I nt eger TpsE xpedi onC 16EnM nut e : I nt eger ti K i Pom peEnSer vi e : St r ng c i C okecar EnSer vi e : St r ng c i

Tr anspor t eur nt er di : St r ng i t i

1. . *

1 1 1

1 0. . n S ubM vt M el nge a N er o : I nt eger um Poi s : Long d D eTi e : D e at m at 0. . n SubM vt C oke N er o : I nt eger um Poi s : Long d D eTi e : D e at m at

Li er e v Test 2 : S. . .

0. . *

C on am i pl cam : . . . a chg m ax : . . . 1 t ar e : I nt . . . f r c t ar : . . . 0. . 1 dat t ar : . . . der t ar : . . .

1 1

num bad : . . . dat cr e : . . . dat m od : . . . t yp bad : . . . num pas : . . . pas m ax : . . . cod na : B. . . i ver com : . . . r ec bad : . . . r em : St r ng i r em com . . . val e : Boo d i der pes : . . . bad act : . . .

C oke N er o : I nt eger um I R D 10 : Long SI _I I R D 20 : Long SI _I I R D 40 : Long SI _I N om : St r ng i

0. . n Ent r epr se i N om : St r ng i

0. . 1 0. . 1 0. . n 0. . n 1 0. . 1 Pl ceO f C bon a har ( f r om C oncept ual odel ck) M P Bat eaux N om : St r ng i 0. . n 0. . n 1 P ceO f M el nge a l a ( f r om C oncept ual odel ck) M P 0. . 1 0. . n Enf our nem ent D h_Enf : D e at D h_Enf _D er s : D e v i at 0. . * 0. . * Pdef R t at esul D ef _Pr evue : D e h_D at Et at _Pr evu : I nt eger Et at _H S_Pr evu : I nt eger D ef _Pr evueC r gee : D e h_D or i at Et at _C r ge : I nt eger or i Et at _H or r ge : I nt eger S_C i Ent r et en : S r ng i t i C m ent ai e : St r ng om r i D h_Enf _Pr ec : D e at D ef _M nm al : D e h_D ii e at O per at on : St r ng i i 0. . * Pdef Li t eR t s esul I d_R t at : I nt eger esul h_I esul at 1 D dR t at : D e D h_Pause : D e at TypeD odel : St r ng eM e i N M achi eC nt : St r ng om n e i l i N U om ser : St r ng i St at usExecut onM odel : I nt eger i e D nE h_Fi xecut eM odel : D e e at Li el St at us_Fi Execut eM odel : St r ng b e l n e i C m ent ai eR t at : St r ng om r esul i 1 0. . *

Bassi n Bassi : Long n Li el : S r ng b e l t i 1

0. . *

1 TypeM a er e t i Pl cePr oduct on a i C ode : St r ng i Pl ceO f C a oke ( f r om C oncept ual odel ck) M P

0. . *

0. . n Si e t Si e : Long t Li el : S r ng b e l t i 1 M vt D ai et l R accor dem ent R accSncb : St r ng i Li el : St r ng b e l i R accC Sam : Bool an kl e 1. . n 1 0. . n D eTi e : D . . at m . Posi on : I nt . . . ti N LVoi : I . . . um t Poi sN : Long d et Poi sBr ut : L. . . d Poi sTheor i ue. . . d q Tar e : Long St at ut : St r ng i 0. . n 0. . n 0. . n 1 M at er e i M at er e : . . . i Li el : St r ng 0. . n b e l i

de t ype 1 1

TypeM at er e : St r ng i i Li el : S r ng b e l t i C eur : St r ng oul i

Pdef Et at E at : I nt eger t Li el : St r ng b e l i S ni cat on : St r ng g fi i i i

0. . 1 0. . * 0. . 1 Enf our nem ent _D er s v i V001 : I nt eger V100 : I nt eger D h_Pause : D e at D h_Jour : D e at D h_M oi : D e s at 0. . 1

0. . n Et at Wagon Et at : St r ng i Li el : St r ng b e l i 1 Wagon N Wago. . . um Poi sBr ut . . . d Tar e : Long Poi sN : . . . d et 1 Poi sTheor . . . d Longueur . . . D eTi eD . . at m . N C um hass. . . de t ype 2 D our neuse ef I d_D our neuse : I nt eger ef Li D our neuse : St r ng b ef i I d_Engi : I nt eger n Pui sanceM axi al : I nt eger s m e Pui sanceC cul ad : I nt eger s al P Pui sanceC cul G r : I nt eger s al T C C r M ul : I nt eger oef or C C r A : I nt eger oef or dd N SecondeEchant onnage : I nt eger br l i TpsM axD our nam ent : I nt eger ef Sur f aceR : I nt eger ef 0. . * 1 D our nem ent ef D ef : D e h_D at D ef _C her m : D e h_D ot at D ef _Pui sance : D e h_D s at D ef _Pr of C h_D l oke : D e i at D ef Pui sanceC e : D e h_D s al at D ef _Pl ni ee : D e h_D a f at

0. . *

Pdef N br eFour P odui om r t 1 D h_Pause : D e at N eFour C br opM odel e : I nt eger s i br M s i 0. * N eFour KD odel e : I nt eger . N eFour C br opPr ogr am m e : I nt eger N eFour KD ogr am m e : I nt eger br Pr N eFour C eal e : I nt eger br opR s i N eFour KD eal e : I nt eger br R s i

0. . n U ne si U ne : Long si 1

0. . n

1 0. . n Se vi r c e Ser vi e : L. . . c Li el : S r ng b e l t i dans 1 0. . n Ve oi Voi : St r ng e i I ndexV e : . . . oi Type : St r ng i Li el : St r ng b e l i O r ent at on. . . i i SensPr v : . . . i Et at : St r ng i Loungueur . . . CD ul eSac : . . . 1 E n et M t t e v N M vt : Long um TypeM vt : S. . . I nt er cal r : . . . e I nver si n : S. . . o TypeM vt S . . . ens D eEnr eg : . . . at D eD at ebut : . . . D eFi : D e at n at Voi D e espose : . . . SensD epose : . . . 1 condui t 1. . n Locom ot ve i N Loco : Long um

0. . n 0. . n 0. . n

de t ype 1

TypeWagon TypeWagon : St r ng i Li el : St r ng b e l i C eur : St r ng oul i

0. . *

0. . 1

C egC at hom age C egC at hom age : St r ng i Li el : St r ng b e l i D our nem ent _C her m ef ot D our nam ent _Pui sance ef s V001 : I nt eger V113 : I nt eger

Pl nni gD our nem ent a n ef D ef _P ni ee : D e h_D a fi l at D ef _V dee : D e h_D al i at D h_Enf _V dee : D e al i at D ef _M ach : D e h_D at D h_Enf _M ach : D e at D h_Enf _P ec : D e r at Et at : I nt eger Et at _Pr ec : I nt eger Et at _H : I nt eger S Et at _R : I nt eger P D ef _C r gee : D e h_D or i at D h_Enf _C r gee : D e or i at Just f cat f : I nt eger ii i C m ent ai e : St r ng om r i i i 1 Ent r et en : St r ng Fl g_D ef _M ach_M aj PR C r ect on : I nt eger a h_D A ESC or i Fl g_D nf _M achAP ESC r ect on : I nt eger a h_E R or i

0. . 1

M esur eSynchr oneBat t er eM nut e i i D h_M esur e : D e at V001 : I nt eger V077 : I nt eger

1 M esur eSynchr oneD er sPause v i D h_M esur e : D e at V001 : I nt eger V100 : I nt eger M esur eS ynchr oneD er sJour v i D h_M esur e : D e at V001 : I nt eger V065 : I nt eger

Par t cper ii Test : St r ng i

M esur eSynchr oneD er sM nut e v i i D h_M esur e : D e at V001 : I nt eger V106 : I nt eger

G r oupLoco N er o : Long um 0. . 1 accom pagne 0. . n Tender Tender : Long

V 0 1: I n t g e e r V 1 7: I n t g e 7 e r

0. . * 0. . * D our nem ent _Pr of C ef l oke i V001 : I nt eger V088 : I nt eger

Pl nni gPost e a n I d_C e : I nt eger ycl Equi e : I nt eger p 0. . * 1

Per sonne I d_P sonne : I nt eger er Pr enom : St r ng i N om : St r ng i D eN ssance : D e at ai at

10 - 27

System Architect (Class Diag.)

(H) Iteration 3 : Construction Design
Pays 1 cod_pay : Integer pay : String Localite cod_loc : String loc : String 1 0..* tiers cod_tie : Integer nom_tie : String adr_tie : String ori : String getCod_tie() 0..n Commande Client
(from ConceptualModelPck)

Element AnalyseCharbon Quantite : Long 0..n AnalyseMelange Quant it e : Long 0..n Nom : String 0..n 1 Origen

0..n

AnalyseCoke Quantite : Long

MessageRejete MsgCommunication Auteur : String Dh_DebutAf fichage : Date Dh_FinAffichage : Date Commentaire : String Response : String 0..1 Id_Msg : Integer DateTraitementMsg : Date NumeroErreur : Integer 1 DescriptionErreur : String EmetteurMsg : String NumeroMsg : Integer LibelleMsg : String SourceErreur : String

M essageTraceChronol ogiqueData DateTraitementMsg : Date EmetteurMsg : Date NumeroMsg : Date NumeroSec : Date Dh_Data : Date EnteteMsg : String Dh_Pause : Date 0..* Dh_Jour : Date Dh_Mois : Date 0..*

TCxListeSerieTempPyrometr e Id_Serie : Integer TypeDeGaz : String PCI : Integer Dh : Date Pyrometreur : String Regleur : String Commentaire : String 0..* Valide : Boolean

TCxSerieTempPyrometre NumCx : Integer Temperature : Integer enregistrerTempCx() 0. .* getTempSerie() 1 0..* Place Name : String 1

Deplacer Dh_DepartG oud : Date Ret ourEauCami on : Bool ean Type : String Fi rm eEntreeFuel : String Ht eurAvant EntreeFuel : Si ngle 0. .nHt eurApresEntreeFuel : Single NoResEnt reeFuel : Single Li trageEntreeFuel : Single HeureEntree : S tring

RecapPauseCoProduit DhPause : Date Ext racteurNord : Single Ext racteurSud : Single VitesseNord : Single VitesseSud : Single DebitNord : S ingl e DebitSud : Si ngle TemperatureVoluteNord : Single TemperatureVoluteS ud : Single AmperageNord : S ingl e AmperageSud : Si ngle RegulationNord : St ri ng RegulationSud : S tring VanneRappoldNord : String VanneRappoldSud : String Pressi onHuileEntreeNord : Single Pressi onHuileEntreeSud : Single Pressi onHuileSortieNord : Single Pressi onHuileSortieS ud : Single VibrationHorizontaleNord : Single VibrationHorizontaleSud : Single VibrationVerticaleNord : Single VibrationVerticaleSud : Single TemperatureExterieureNord : Single TemperatureExterieureSud : Single CondensationDebi t : Single CondensationAnal yse : Single LavageDebi t : Single LavageAnal yse : Single CSFDebit : Single CSFA nalyse : Single BiologiqueDebit : S ingle BiologuiqueAnalyse : Single VenturiDebit : S ingl e VenturiTemperature : Single VenturiPh : S ingl e Brigadier : String Operateur : S tring OperateurGazom etre : String I ti nerant Coproduit : String I ti nerant BioG azometre : String ChaguerGourdon : String HorsQuota : String TempSortieCTH1 : S ingle TempSortieCTH2 : S ingle TempSortieCTH3 : S ingle TempSortieCTH4 : S ingle TempSortieE GR1 : Single TempSortieE GR2 : Single TempSortieE GR4 : Single TempSortieE GR3 : Single TempEntreeLaveur5Nord : Single TempEntreeLaveur5Sud : Single TempEntreeLaveur1Nord : Single TempEntreeLaveur1Sud : Single Pressi onEtDebitV apeur : String Niv eauRes500 : Si ngle Niv eauResB 500 : Single Niv eauRes1000 : Si ngle Niv eauRes800 : Si ngle Niv eauRes6514 : Si ngle PosteE met teur : String Detec teurCO : String Commentaire : String SignatureBrigadier : S tring CommentaireOperateur : String SignatureOperateurTechnique* : String VolumeResFuel 6509 : Single HauteurResFuel 6509 : Single VolumeResFuel 6508 : Single HauteurResFuel 6508 : Single VolumeResFuel 6511A : Single HauteurResFuel 6511A : Single VolumeResFuel 6511B : Single HauteurResFuel 6511B : Single Laveur1NordDebit : Single Laveur1NordPassage : Single Laveur1S udDebit : Single Laveur1S udPassage : Single PerteFuel : Single HauteurSoudeA vant : Single HauteurSoudeA pres : Single ConsommationSoude : Single encoderCahierElect ronique()

Granulometrie Interval : String Nom : String 0. .n 0..n

TcxTypeDeMesure Id_TypeDeMesure : Integer 1 Libelle : String RecapJourCoProduit

0..*num_com : I nteger ent_srt : Boolean getCommande() 0..* 0..*

Post 1..* pst_num : Integer dat_pst : Dat e 0..*

Charbon Number : Integer Nom : String 1

Melange Num ero : Int eger Swel li ngIndContM ax : Long Swel li ngIndDil Max : Long Nom : St ri ng 0. .n 0..n MvtCharbon Numero : Integer Poids : Long DateTime : Date 0..1 1 ComposeMelange Quantite : Integer 0. .n 0..n SubMvtM elange Numero : Integer Poids : Long DateTime : Date 0..n 1 Pl aceOfMelange
( from Conceptual ModelPc k )

GranCoke Quantite : Integer

0..*

0..*

Fam_article fam_art : String lib_fam : String ori : String 1

Fournisseur
(from ConceptualModelPck)

GranMelange Quantite : Integer 0..n 0..n

Sales Poids : Long DateTime : Date 0..n

1 1 Four Id_Four : Integer 1 1 1 0..* 1 1..2

Pi edroi t Id_Pdt : Integer Libelle : String 0..* 1 Bat terie

Pesee Bascule bas_id : Integer 1 bas : String 0..* Badge 0..1 num_bad : Integer dat_cre : Date dat_mod : Date typ_bad : String num_pas : Integer pas_max : Integer 1 cod_ina : Boolean ver_com : String rec_bad : String 1 rem : String rem_com : String valide : Boolean der_pes : String bad_act : Boolean expireBadge() getBadgeDisponible() libererBadge() getValiditeBadge() MvtDetail Dat eTim e : Date Posit ion : Int eger Num LVoit : I nteger Poi dsNet : Long Poi dsB rut : Long Poi dsT heori que : Long 0. .nTare : Long St atut : St ri ng 0..n creerConv oi() di s soudreC onvoi () get Pos ti on() i setPosi ti on() EnteteMvt NumMvt : Long TypeMvt : S tring Intercal er : String Inversion : String TypeMvt Sens 1 St ri ng : DateEnreg : Date DateDebut : Date DateFin : Date VoieDespose : String SensDepose : St ri ng inverserConvoi() effectuerMv t() 0..* Livraison

concerne Test2 : String 1 Article c od_art : I nteger c od_env : String l ib_art : String 0..* l ibel le : String ori : String 1..*

MsgGroupe Id_GroupMsg : Integer LibelleMsg : String TypeMsg : String 1

num : Integer DateTime : Date pesee1 : Integer Transporteur pesee2 : Integer pes_val : Boolean pes_ann : Boolean rem : String checkInterdictionTransporteur() rem_sys : String interdireTransporteur() status : String 1..* lib_pre : String 0..* 1 cod_pre : Integer 0..* Camion interdit : String pla_cam : String chg_max : Integer tare : Integer frc_tar : Integer dat_tar : Date der_tar : Date assignerBadge() Bassin Bassin : Long Libelle : String 1 0..n Site Site : Long Libelle : String 1 0..n Usine Usine : Long 1 0..n Service Service : Long Libelle : String 1..n 1 Voie Voie : String IndexVoie : Long Type : String Libelle : String dans 0..n Orientation : String 1 SensPriv : String Etat : String Loungueur : Long CulDeSac : Boolean 1 encoderPesee() supprimerPesee()

0..n

0. .n 0..n MvtMelange

M vtCoke Numero : Integer Poids : Long 1 0..1 DateTime : Date Retourn : Boolean 1 0..n SubMvtCoke Numero : Integer Poids : Long DateTime : Date 0..n 1

0..n

Numero : Integer Podis : Long 0..n DateTim e : Date 1

encoderSerieTempCx() validerSerie() encoderCommentaire() PdefDHPourDebug historiqueTCx5-22() ConsigneTempsCuisson DhMaintenant : Date Id_Consigne : Integer DhAvant : Date Dh_DebutChangement : Date ConsTpsCuis_KoppersDidier : Integer ConsTpsCuis_Coppee : Integer 0..* 1 1 1 1 0..*

cod_liv : Integer lib_liv : String 1 ori : String 0..n

0..* Livere

0..*

Test2 : String 0..1 0..1 Envoi Numero : Integer 0..n

SubM vtCharbon Numero : Integer Poids : Long DateTime : Date 0..n 1

Coke 0..n Numero : Integer IRSID_I10 : Long Entreprise IRSID_I20 : Long Nom : String IRSID_I40 : Long Nom : String 0..* Enfournement Dh_Enf : Date Dh_Enf_Divers : Date

Id_Batterie : Integer Libelle : String Id_PdtDebut : I nteger Nom : St ri ng NumFourDeb : Int eger NbrFour : Integer NbrPdt : String 0..1

PdelListeHeurePourM odeleLight Id_Progr : Integer 0..* HeureFour : Date PlanningEntretien

DhJ our : Dat e Vol umeRes2Goudron : I nteger Vol umeRes3Goudron : I nteger Vol umeRes4Goudron : I nteger Vol umeRes5Goudron : I nteger Vol umeRes6Goudron : I nteger Vol umeRes7Goudron : I nteger Vol umeRes8Goudron : I nteger Vol umeRes9Goudron : I nteger Vol umeRes10Goudron : I nteger Cpt eurFuel VersCent ral Avant : Int eger Cpt eurFuel VersCent ral Apres : Integer LitrageFuelVers entral : Integer C PDefParametre

0..*

CamionCoProduit 0..* NoPlaque : String

0..* PdefResultat Dh_Def_Prevue : Date Etat_Prevu : Integer Etat_HS_Prevu : Integer Dh_Def_PrevueCorrigee : Date Etat_Corrige : Integer Etat_HS_Corrige : Integer Entretien : String Commentaire : String Dh_Enf_Prec : Date Dh_Def_Minimale : Date Operation : String enregistrePlanningPropose() enregistrePlaningValide() 1 0..* PlanningDefournement 0..1 1

0..* Dh_Debut : Date DureeEnMi nute : Integer

0..1

0..1

0..n

0..1 Bateaux Nom : String

Pl aceOfCharbon
(from ConceptualModelPck)

0..1 1

0..n

enfournementE3() enfournementE1() txUtilisationE3() 1 0..*

0..*

TypeMatiere Matiere Matiere : String Libelle : String de type 1 0. .n TypeM ati ere : String Li bell e : St ri ng 1 Coul eur : String

PlaceProduct ion Code : String

PlaceOfCoke
(from Conceptua ModelPck) l

PdefListeResult 0..* Id_Resul tat : I nteger 1 Dh_IdResultat : Date Dh_Pause : Date TypeDeModele : String NomMachineCli ent : String NomUser : String StatusExecuti onModel e : I nteger Dh_FinExecuteModele : Date LibelleStatus_Fi nExecuteM odele : String CommentaireResultat : String 0..1 startModelePV () startModeleLi ght() setResultat() imprimePlanni ng()

PdefEtat Etat : Integer Libelle : String 1 Signification : String

Raccordement RaccSncb : String Libelle : String RaccCklSam : Boolean

0..n 1 0..n

0. .1 0. .n 0..* 0..1 Enfournement_Divers V001 : Integer V100 : Integer Dh_Pause : Date Dh_Jour : Date Dh_Mois : Date

0..*

Wagon 0..n NumWagon : Long PoidsBrut : Long Tare : Long 1 PoidsNet : Long PoidsTheorique : Long Longueur : Long DateTimeDebChomage : Date NumChassis : Integer setDebutChomage() setFinChomage() calculerTempsChomage() GroupLoco Numero : Long 1 conduit 1. .n Locomotive NumLoco : Long 0..1 accompagne 0. .n

EtatWagon Etat : String 1 Libelle : String de type 2 0..n TypeWagon TypeWagon : String de ty pe Libelle : String 0..n 1 Couleur : String 0..n CategChomage 0..1 CategChomage : String Libelle : String tempsChomageMax()

Defournement Dh_Def : Date Dh_Def_Cotherm : Date Defourneuse Dh_Def_Puissance : Date Dh_Def_ProfilCoke : Date Id_Defourneuse : Integer 0..* Dh_DefPuissanceCale : Date LibDefourneuse : String 1 Dh_Def_Planifee : Date Id_Engin : Integer 0..* PuissanceMaximale : Integer PuissanceCalculPad : Integer Defournament_Puissance Def ournem ent_Cotherm PuissanceCalculTGr : Integer V001 : Integer CoefCorrMul : Integer V001 : Integer V113 : Integer CoefCorrAdd : Integer V177 : Integer NbrSecondeEchantillonnage : Integer enregistrementPuissance() TpsMaxDefournament : Integer enregistrementTemperatureCotherm() cartePuissanceBatterie() SurfaceRef : Integer carteCothermBatterie() cartePuissanceFour() carteCothermFour() evolution3DPic() moyenneTempCotherm() evolution3DPAD() ecartTypeTempCotherm() Def ournement_ProfilCok e evolution3DID() courbesTemperatureSaumon() V001 : Integer historiqueCourbesTemperatureSaumon() evolutionPuissanceMoyenneBatterie() V088 : IntegerpicMoyDerniersDefournements() checkCarneaux() nbrFoursCaleMoisPuissanceMois() enregistrementProfilCoke() encoderCahierElectronique()

Dh_Def_Planifiee : Date Dh_Def_Validee : Date Dh_Enf_Validee : Date Dh_Def_Mach : Date Dh_Enf_Mach : Date Dh_Enf_Prec : Date Etat : Integer Etat_Prec : Integer Etat_HS : Integer 1 Etat_RP : Integer Dh_Def_Corrigee : Date Dh_Enf_Corrigee : Date Justificatif : Integer Commentaire : String Entretien : String Flag_Dh_Def_Mach_MajAPRESCCorrection : Integer Flag_Dh_Enf_MachAPRESCorrection : Integer validationEnfournement() validationDefournement() setPlanning()

PdefNombreFourProduit 1 0..* Dh_Pause : Date NbreFourCopModelise : Integer NbreFourKDModelise : Integer NbreFourCopProgramme : Integer NbreFourKDProgramme : Integer NbreFourCopRealise : Integer NbreFourKDRealise : Integer

Id : Integer DateDerniereModif : Date Commentaire : String Dh_PauseEnCours : Date TpsCuissonCoppee : Integer TpsCuissonKoppers : Integer DelaiEntreDefournEtEnfourn : Integer EcartMaxTpsCuissonCoppee : Integer EcartMaxTpsCuissonKoppers : Integer EcartSurProgrTolereCoppee : Integer EcartSurProgrTolereKoppers : Integer DefaultDelaiEntreDefEtEnf : Integer ModifDhMachineAutorisee : Integer DelaiEnSecondeDuRefreshAutoInterface : Integer TimeOutExecuteModele : Integer NbrHeureAvantPauseCouranteAVisualiser : Integer NbrHeureApresPauseCouranteAVisualiser : Integer PasswordOption : String AnimationVideo : Integer M_PV_Enabled : Integer M_PV_kdpapHS : Integer EntretienHeureMin : Integer EntretienHeureMax : Integer EntretienDureeMin : Integer EntretienDureeMax : Integer EntretienPasMin : Integer MesureSynchroneBat terieM inut e Dh_M esure : Date V001 : Int eger V077 : Int eger MesureSynchroneDiver sMinute Dh_Mesure : Date V001 : Integer V106 : Integer

RecapPauseFour DhPause : Date NomAjusteur : String CommentaireAjusteur : String SignatureAjusteur : String NomElectrician : String CommentaireElectrician : String SignatureElectrician : String NomContremaitre : String AssistantContremaitre : String CommentaireContremaitre : String SignatureContremaitre : String NbreDefournementCoppee : Single NbreDefournamentKoppers : Single NbreDefournamentDidier : Single EtatCuissonCoppee : String EtatCuissonKoppers : String EtatCuissonDidier : String PlateauCoppeeNettoyeCoteCoke : String PlateauKoppersNettoyeCoteCoke : String PlateauDidierNettoyeCoteCoke : String PlateauCoppeeNettoyeCoteMachine : String PlateauKoppersNettoyeCoteMachine : String PlateauDidierNettoyeCoteMachine : String TpsExtinctionEnSeconde : Integer TpsEgouttageEnSeconde : Integer TpsExpeditionCK16EnMinute : Integer PompeEnService : String CokecarEnService : String

MesureSynchroneDiver sPause Dh_Mesure : Date V001 : Integer V100 : Integer

MesureSynchroneDi ver sJour Dh_Mesure : Date V001 : Integer V065 : Integer

Participer Test : String

Personne 0..* PlanningPoste 0..*Id_Cycle : Integer Equipe : Integer 0..* Id_Personne : Integer Prenom : String 1 Nom : String DateNaissance : Date

Tender Tender : Long

10 - 28

System Architect (Class Diag.)

(I) Itration 4 : Construction Implementation

Pays cod_pay : INT pay : VARCHAR(255) 1 <<Non-Identifying>>

<<Identifying>> 1

Element Nom : VARCHAR(255) 1

<<Identifying>> MesureSynchroneDiversPause Dh_Mesure : DATETIME V001 : INT V100 : INT Granulometrie Interval : VARCHAR(255) Nom : VARCHAR(255) MesureSynchroneBatterieMinute Dh_Mesure : DATETIME V001 : INT V077 : INT MesureSynchroneDiversMinute Dh_Mesure : DATETIM E V001 : INT V106 : INT Place Name : VARCHAR(255) 1 <<Non-Identifying>> 0..* RecapJourCoProduit DhJ our : D ATETIM E VolumeRes2Goudron : I NT VolumeRes3Goudron : I NT <<Identifying>> VolumeRes4Goudron : I NT VolumeRes5Goudron : I NT VolumeRes6Goudron : I NT 0..* 1 VolumeRes7Goudron : I NT VolumeRes8Goudron : I NT VolumeRes9Goudron : I NT VolumeRes10Goudron : I NT Cpt eur FuelVersC ent ral Av : INT ant Cpt eur FuelVersC ent ral Ap es : IN T r Lit rag eFuelVersCen ral : IN T t

<<Non-Identifying>> <<Non-Identifying>>

0..*

0..* Localite cod_loc : VARCHAR(255) loc : VARCHAR(255) cod_pay : INT 1 <<Non-Identifying>> 0.. * tiers cod_tie : INT nom_tie : VARCHAR(255) adr_tie : VARCHAR(255) ori : VARCHAR(255) cod_loc : VARCHAR(255) 1 <<Identifying>> 0..1 Pesee num : INT DateTime : DATETIME pesee1 : INT pesee2 : INT pes_val : BIT pes_ann : BIT rem : VARCHAR(255) rem_sys : VARCHAR(255) status : VARCHAR(255) lib_pre : VARCHAR(255) cod_pre : INT num_bad : INT bas_id : INT pla_cam : VARCHAR(255) cod_liv : INT <<Non-Identify ng>> 1 i 1 <<Identifying>> 1 0..1 Fournisseur cod_tie : INT 1 Bascule bas_id : INT bas : VARCHAR(255) <<Identi fying>> <<Non-Identifying>> 0..* concer ne num_com : INT cod_liv : INT 0..* Fam_article fam_ar t : V ARCHAR (255) li b_fam: VAR CHAR(255) o ri : VARC HAR(255) 1 <<Non-Identifying>> 1..* 1 0..* <<Non-Identifying>> 0..1 1 Livraison cod_liv : INT lib_liv : VARCHAR(255) ori : VARCHAR(255) Numero : FLOAT(53, 0) <<Identifying >> 1 0..* 0..* <<Non-Identifying>> 1 Badge num_bad : INT dat_cre : DATETIME dat_mod : DATETIME typ_bad : VARCHAR(255) num_pas : INT pas_max : INT cod_ina : BIT ver_com : VARCHAR(255) rec_bad : VARCHAR(255) rem : VARCHAR(255) rem_com : VARCHAR(255) valide : BIT der_pes : VARCHAR(255) bad_act : BIT 0..* Livere c od_l iv : IN T c od_ar t : INT <<Identifying>> 0..* 1 Article c od_ t : INT ar c od_ : VARC HAR( 255) env li b_a : VARCH AR(255) rt li belle : VARCHAR (255) ori : VARC HAR( 255) fam_ t : VARCHAR (255) ar 1 0..* <<I d fying>> enti 0..1 Client cod_tie : INT 1 <<Non- Identifying>> Comma nde 0..* num_com : INT ent_srt : BIT cod_tie_Clt : INT Cod_tie_Fou : INT 1 <<Non- Identif y g>> in 1 1..* Post pst_num : INT dat_pst : DATETIME cod_art : INT num_com : INT 0..* 0..* Charbon Number : FLOAT(53) cod_pay : INT Nom : VARCHAR(255) 1

AnalyseCharbon Q uant ite : BIGI NT Nom : VARCHA R(255) Numero : FLOAT( 53)

<<Identifying>>

0..*

MesureSynchroneDiversJour Dh_Mesure : DATETIME V001 : INT V065 : INT

1 0..*

1 <<Identifying>> 0..1

AnalyseCoke Quantite : BIGINT Nom : VARCHAR(255) Numero : FLOAT(53)

0..* AnalyseMelange Quantite : BIGINT Nom : VARCHAR(255) Numero : FLOAT(53) 0..1 <<Identifying>> Melange Numero : FLOAT(53) SwellingIndContMax : BIGINT SwellingIndDilMax : BIGINT Nom : VARCHAR(255) 1 <<Non-Identifying>> 1 0..* GranMelange <<Identifying >> Quantite : INT Interval : VARCHAR(255) Numero : FLOAT(53) 0..* <<Identifying>>

Deplacer Dh_DepartGoud : DATETIME RetourEauCamion : BIT Type : 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 0.. *

GranCoke Quantite : INT Interval : VARCHAR(255) Numero : FLOAT(53) 0.. * <<Identifying>>

0..*

<<Identifying>>

MsgCommunication Id_Msg : INT Auteur : VARCHAR(255) Dh_DebutAffichage : DATETIME Dh_FinAffichage : DATETIME Commentaire : VARCHAR(255) Response : VARCHAR(255) Id_GroupMsgOri : INT Id_GroupMsgDst : INT Coke Numer o : FLOAT( 53) IR SID_I10 : BIGI NT IR SID_I20 : BIGI NT IR SID_I40 : BIGI NT Nom : VARCHAR(255) 1 0..1 <<Identifying>>

<<Non- Identify ng >> i <<Identifying >> 1 CamionCoProduit NoPlaqu e : VAR CHAR(255)

0..*

MsgGroupe 1 Id_GroupMsg : INT LibelleMsg : VARCHAR(255) TypeMsg : VARCHAR(255)

RecapPauseFour DhPause : DATETIME NomAj usteur : VARCHAR (255) Comme aireAj usteur : VARCHAR (255) nt Sig n u at reAjusteur : VARC HAR( 25 5) NomEl ectrician : VARC HAR( 255 ) Comme aireEl ectr ic ian : VAR CHAR(255) nt Sig n u at reElectri ci an : VARCH AR(255) NomC o remai tr e : VARCH AR( 2 nt 55) As sistantC ontremai tr e : VARC HAR( 25 5) Comme aireC ontremai tr e : VARCH AR( 255) nt Sig n u at reContr em aitre : VAR CHAR (255) Nbr eDefournementC oppee : FLOAT( 32, 0) Nbr eDefournamentKoppers : F L AT(32, 0) O Nbr eDefournamentD idier : FLOAT( 32, 0) Etat Cuiss onCoppee : VAR CHAR(255) Etat Cuiss onKopper s : VARCH AR(255) Etat Cuiss onDidi er : VAR CHAR(255) Plat ea uCoppeeNettoyeCoteCoke : VARC HAR( 255) Plat ea uKoppersNetto y ot eCok : V ARCHAR (25 5) eC e Plat ea dier Nett oye CoteCoke : VARC HAR( 255) uDi Plat ea uCoppeeNettoyeCoteM achi n : VARCHAR (255) e Plat ea uKoppersNetto y ot eMac hine : VARC HAR( 255) eC Plat ea dier Nett oye CoteM a n : VARCHAR (255 ) uDi chi e TpsEx inc ti onEnSeco nde : INT t TpsEgouttageEnSeconde : I NT TpsEx pedit ionCK16EnMi nut e : INT Pom peEnService : VAR CHAR(255 ) Cokecar EnService : VAR CHAR(255)

0..* <<Non-Identifying>>

<<Non- Identif y ng>> i

<<Identifying>>

<<Identi fying>>0..* <<Non-Identify ng>> i 1 1 1 <<Non-Identifying>> MvtCok e Numero : FLOAT(53) Poids : BIGINT DateTime : DATETIME Retourn : BIT NumeroCoke : FLOAT(53) NumeroMelange : FLOAT(53) 1 Sales <<Identifying>> 1 0..* Poids : BIGIN T Date me : DAT ETIME Ti Nom : VARCHAR(255) Num ro : FLOAT(53, 0) e 0.. * <<I den ti fying>> 1 <<Non-Identifying>> Entreprise Nom : VARCHAR(255) 0..* 0..* Enfournement _D ivers V001 : INT V100 : INT Dh_Pause : DATETIME Dh_Jour : DATETIME Dh_Mois : DATETIME Dh_Enf : DATETIME 0..1 0.. * <<Identifying>> 1 <<Non-Identifying >> 1 Enfournement <<Non-Identifying>> <<Non-Identifying>> <<Identifying>> 1 0..*

1 MessageRejete Id_Msg : INT DateTraitementMsg : DATETIME NumeroErreur : INT DescriptionErreur : VARCHAR(255) EmetteurMsg : VARCHAR(255) NumeroMsg : INT LibelleMsg : VARCHAR(255) SourceErreur : VARCHAR(255) 1

TCxSerieTempPyrometre NumC x : INT Temperature : I NT Id_Ser ie : INT 0..*

TcxTypeDeMesure Id_TypeDeMesure : INT Libelle : VARCHAR(255) 1 <<Non-Identifying>>

Transporteur interdit : VARCHAR(255) pla_cam : VARCHAR(255) cod_tie : INT

<<Non-Identify ng>> i 0..*

MvtCharbon <<Non-Identifying>> 1 Numero : FLOAT(53, 0) Poids : BIGINT DateTime : DATETIME Number : FLOAT(53, 0) NumberEnvoi : FLOAT(53, 0) 1

1..* <<Non-Identifying>> 0..* 0..* 1 <<Non-Identifying>>

Mvt Melang e Numero : FLOAT(53) Podis : BIGINT DateTime : DATETIME NumeroMelange : FLOAT(53) 1 <<Identifying >> 0..* <<Identifying>> 0..* <<Non-Identifying>> ComposeMelange Quantite : INT NumeroCharbon : FLOAT(53) NumeroMelange : FLOAT(53) 1

<<Identi fying>>

0.. 1

0.. *

TCxListeSerieTempPyrometre Id_Serie : INT TypeDeGaz : VARCHAR(255) PCI : INT Dh : DATETIME Pyrometreur : VARCHAR(255) Regleur : VARCHAR(255) Commentaire : VARCHAR(255) Valide : BIT Id_TypeDeMesure : INT Id_Pdt : INT 0..* <<Non-Identifying>>

Cami on pla_cam : VARCHAR(255) chg_max : INT tare : INT frc_tar : INT dat_tar : DATETIME der_tar : DATETIME num_bad : INT cod_pay : INT

1 <<Non- Identifying>> 0..1

<<Non-Identify ng>> i <<Non-Identifying>> 0..1 0..1 Envoi Numero : FLOAT(53, 0) Nom : VARCHAR(255) 0..* <<Non-Identifying>> 0..*

0..*

0..1

Bassin Bassin : BIGINT Libelle : VARCHAR(255) 1 <<Identifying>> 0..* Site Site : BIGINT Libelle : VARCHAR(255) Bassin : BIGINT 1 <<Identifying>> 0..* Raccordement RaccSncb : VARCHAR(255) Libelle : VARCHAR(255) RaccCklSam : BIT Bassin : BIGINT Site : BIGINT Usine : BIGINT Service : BIGINT Voie : VARCHAR(255) 1..* Usine Usine : BIGINT Bassin : BIGINT Site : BIGINT 1 <<Identifying>> Voie 0..* Service Service : BIGINT Libelle : VARCHAR(255) Bassin : BIGINT Site : BIGINT Usine : BIGINT <<Identifying>> 1 0..* Voie : VARCHAR(255) IndexVoie : BIGINT Type : VARCHAR(255) Libelle : VARCHAR(255) Orientation : VARCHAR(255) SensPriv : VARCHAR(255) Etat : VARCHAR(255) Loung ueur : BIGINT CulDeSac : BIT Service : BIGINT Bassin : BIGINT Site : BIGINT Usine : BIGINT <<Identifying>> MvtDetail NumWagon : BIGINT NumMvt : BIGINT DateTime : DATETIME Position : INT NumLVoit : INT PoidsNet : BIGINT PoidsBrut : BIGINT PoidsTheorique : BIGINT Tare : BIGINT Statut : VARCHAR(255) Numero : FLOAT(53, 0) Matiere : VARCHAR(255) RaccSncb : VARCHAR(255) Bassin : BIGINT Site : BIGINT Usine : BIGINT Service : BIGINT Voie : VARCHAR(255) 0..* 1 <<Identifying>> 1 1

SubMvtCharbon Numer o : FL OAT( 53 0) , Poids : BIGIN T Dat eTi m : DAT ETIME e Numer oMvtChar bon : F L AT(53) O Code : VARC HAR( 25 5) 0..*

SubMvtMelange Numero : FLOAT(53, 0) Poids : BIGINT DateTime : DATETIME NumeroMvtMelange : FLOAT(53) Code : VARCHAR(255) 0..*

0..1 <<Non-Identifying >> Bateaux Nom : VARCHAR(255)

SubMvtCoke Numero : FLOAT(53, 0) Poids : BIGINT DateTime : DATETIME NumeroMvtCoke : FLOAT(53) Code : VARCHAR(255)

MessageTraceChronologiqueData DateTraitemen tMsg : DATETIME EmetteurMs g : DATETIME NumeroMsg : D ATETIM E NumeroSec : DATETIME Dh_Data : DATETIME EnteteMsg : VARC HAR(255) Dh_Pause : DATETIME Dh_Jour : D ATETIM E Dh_Moi s : DATETI ME Id_M sg : INT Id_Four : INT 0..*

PDefParametre Id : INT DateDerniereModif : DATETIME Commentaire : VARCHAR(255) Dh_PauseEnCours : DATETIME TpsCuissonCoppee : INT TpsCuissonKoppers : INT DelaiEntreDefournEtEnfourn : INT EcartMaxTpsCuissonCoppee : INT EcartMaxTpsCuissonKoppers : INT EcartSurProgrTolereCoppee : INT EcartSurProgrTolereKoppers : INT DefaultDelaiEntreDefEtEnf : INT ModifDhMachineAutorisee : INT DelaiEnSecondeDuRefreshAutoInterface : INT TimeOutExecuteModele : INT NbrHeureAvantPauseCouranteAVisualiser : INT NbrHeureApresPauseCouranteAVisualiser : INT PasswordOption : VARCHAR(255) AnimationVideo : INT M_PV_Enabled : INT M_PV_kdpapHS : INT EntretienHeureMin : INT EntretienHeureMax : INT EntretienDureeMin : INT EntretienDureeMax : INT EntretienPasMin : INT Id_Batterie : INT 0..*

1 Piedr oit Id_Pdt : INT Libelle : VARCHAR(255) Id_Four : INT Id_Batterie : INT 0..*

<<Non-Identifying>> 1

<<Non-Identifying>>

<<Non-Identifying >>

<<Non-Identifying >> 1 1.. 2

PdefDHPourDebug DhMaintenant : DATETIME DhAvant : DATETIME Id_Batterie : INT 0..*

0..* Matiere 1 Matiere : VARCHAR(255) Libelle : VARCHAR(255) TypeMatiere : VARCHAR(255) 0..* TypeMatiere 1 TypeMatiere : VARCHAR(255) Libelle : VARCHAR(255) Couleur : VARC HAR(255)

<<Non-Identifying>>

PlaceOfCharbon Code : VARCHAR(255) <<Non-Identifying>> <<Non-Identifying>> 0..1

PlaceOfMelange Code : VARCHAR(255) 0..1 <<Identifying >>

<<Non-Identifying>>

0..*

0..*

0..*

Dh_Enf : DATETIME Dh_Enf_Divers : DATETIME Dh_Def_Planifiee : DATETIME Id_Four : INT Code : VARCHAR(255) 0.. *

0..*

Four Id_Four : INT Id_Batterie : INT 1 1

1 <<Non-Identifying>> <<Non-Identifying>> 0..* 1 Batteri e 1 Id_Batterie : INT Libelle : VARCHAR(255) Id_PdtDebut : INT Nom : VARCHAR(255) NumFourDeb : INT NbrFour : INT NbrPdt : VARCHAR(255) 1 1

<<Non-Identifying>> PdelListeHeurePourModeleLight 0..1 1 <<Non-Identifying>> 0..* <<Non-Identif y ng>> i PlanningEnt reti en <<Non-Identifying>> 1 0.. * Dh_Debut : DATETIME DureeEnMinute : INT Id_Batterie : INT Id_Progr : INT HeureFour : DATETIME Id_Batterie : INT

RecapPauseCoProduit DhPause : DATETIME ExtracteurNord : FLOAT(32, 0) ExtracteurSud : FLOAT(32, 0) Vites seNord : FLOAT(32, 0) Vites seSud : FLOAT(32, 0) DebitNord : FLOAT(32, 0) DebitSud : FLOAT(32, 0) TemperatureVolut eNord : FLOAT(32, 0 ) TemperatureVolut eSud : FLOA T(32, 0) Amperag eN ord : FLOAT(32, 0) Amperag eSud : FLOAT (32, 0) RegulationNord : VARCHAR(255) RegulationSud : VARCH AR(255) Vanne RappoldN ord : VARCHAR(255 ) Vanne RappoldSud : VAR CHAR(255) PressionH uileEntreeNord : FLO AT(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 : FLO AT(32, 0) VibrationVerticaleNord : FLOA T(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 : VARC HAR(255) Oper a teur : VARCHAR (255) Oper a teurGazometre : VARCHAR(255 ) Itiner a ntCoproduit : VARCHAR( 2 55) Itiner a ntBioGazometre : VARC HAR(25 5) ChaguerG ourdon : VARCHAR(255) Hors Quota : 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) PressionEtDebit Vapeur : VARCHAR( 2 55) NiveauRes500 : FLOAT(32, 0) NiveauResB500 : FLOAT(32, 0) NiveauRes1000 : FLOAT(32, 0 ) NiveauRes800 : FLOAT(32, 0) NiveauRes6514 : FLOAT(32, 0 ) PosteEmet teur : VARCHAR(255) Det e cteurCO : VARCH AR(255) Commentair e : VARCH AR(255) Sig n atureBr igadier : VARCHAR(255) Commentair eOperateur : VARCHAR( 2 55) Sig n atureOperateurTechniq ue : VARCHAR( 255) VolumeResFuel6509 : FLOAT(32 0) , HauteurRes Fuel6509 : FLOAT (32, 0) VolumeResFuel6508 : FLOAT(32 0) , HauteurRes Fuel6508 : FLOAT (32, 0) VolumeResFuel6511A : FLOAT(32, 0) HauteurRes Fuel6511A : FLOA T(32, 0) VolumeResFuel6511B : FLOAT(32, 0) HauteurRes Fuel6511B : FLOA T(32, 0) Laveur1NordDebit : FLOAT(32 , 0) Laveur1NordPass age : FLOAT(32, 0) Laveur1SudDebi t : FLOAT(32, 0 ) Laveur1SudPassage : FLOAT( 3 0) 2, Per teFuel : FLOAT(32, 0) HauteurSoudeAvant : FLOAT(32, 0) HauteurSoudeApr es : F LOAT(32, 0) ConsommationSoude : FLOAT(32, 0)

<<I d fying>> enti 0..* <<Identifying>> EtatWagon Etat : VARCHAR(255) Libelle : VARCHAR(255) <<Non-Identifying>> 1 Wagon NumWagon : BIGINT PoidsBrut : BIGINT Tare : BIGINT PoidsNet : BIGINT PoidsTheorique : BIGINT Longueur : BIGINT DateTimeDebChomage : DATETIME NumChassis : INT Etat : VARCHAR(255) TypeWagon : VARCHAR(255) CategChomage : VARCHAR(255) 1 <<Identifying>> 0..*

1 1 1 PlaceProduction Code : VARCHAR(255) 1 <<Identifying>> 0..1 PlaceOfCoke Code : VARCHAR(255) 1 0..* <<Non- Identifying>> 0..* 1

<<Non-Identifying >>

<<Non-Identifying>> <<Non- Identif y ng>> i

<<Identifying>>

0..* Type Wagon TypeWag on : VARCHAR(255) Libelle : VARCHAR(255) Couleur : VARCHAR(255) <<Non- Identifying >> 1 0..* ConsigneTempsCuisson Id_Consigne : INT Dh_DebutChangement : DATETIME ConsTpsCuis_KoppersDidier : INT ConsTpsCuis_Coppee : INT Id_Batterie : INT

EnteteMvt NumMvt : BIGINT TypeMvt : VARCHAR(255) Intercaler : VARCHAR(255) Inversion : VARCHAR(255) TypeMvtSens : VARCHAR(255) DateEnreg : DATETIME DateDebut : DATETIME DateFin : DATETIME VoieDespose : VARCHAR(255) SensDepose : VARCHAR(255)

PlanningDefournement 0..* 0..* Dh_Def_Planifiee : DATETIME Dh_Def_Validee : DATETIME Dh_Enf_Validee : DATETIME Dh_Def_Mach : DATETIME Dh_Enf_Mach : DATETIME Dh_Enf_Prec : DATETIME Etat : INT Etat_Prec : INT Etat_HS : INT Etat_RP : INT Dh_Def_Corrig ee : DATETIME Dh_Enf_Corrigee : DATETIME Justificatif : INT Commentaire : VARCHAR(255) Entretien : VARCHAR(255) Flag_Dh_Def_Mach_MajAPRESCCorrection : INT Flag_Dh_Enf_MachAPRESCorrection : INT Id_Resultat : INT Dh_Def_Prevue : DATETIME Id_Four : INT 1 Defournament _Puissa e nc Dh_Def : DATETIME Id_Four : INT V001 : INT V113 : INT Defournement_ProfilCoke Dh_Def : DATETIME Id_Four : INT V001 : INT V088 : INT <<Identifying>> 0..1 1 <<Non- Identif y ing>>

0..* PdefResultat Id_Result at : I NT Id_Result at : I NT Dh_Def_Prevue : D ATETIM E Etat _Prevu : INT Etat _HS_Prevu : IN T <<Non-Identifying>> Dh_Def_PrevueCorrigee : DATETI ME Etat _Corrig e : INT 1..* 0..1 Etat _HS_Corrig e : INT Entreti e : VARCHAR (255) n Comme air e : VARCH AR(255) nt Dh_Enf_Prec : DATETIME Dh_Def_Minimale : DATETIME Oper a tion : VAR CHAR(255) Id_Four : INT 0..* <<Identifying>>

0..* <<Non-Identifying>> 0..1 CategC h oma e g CategChomage : VARCHAR(255) Libelle : VARCHAR(255) Defourneuse Id_Def o urneuse : INT LibDef o urneuse : VAR CHAR(255) Id_Engin : INT PuissanceM ax m : INT i ale PuissanceC al culPad : IN T PuissanceC al culTGr : INT CoefC o Mul : INT rr CoefC o Add : INT rr Nbr SecondeEchantill onnage : I NT TpsMaxDefournament : INT Surface ef : I NT R

Def our nement Id_Four : INT Dh_Def : DATETIME Id_Four : INT Dh_Def_Cotherm : DATETIME Dh_Def_Puissance : DATETIME Dh_Def_ProfilCoke : DATETIME Dh_DefPuissanceCale : DATETIME Dh_Def_Planifee : DATETIME Dh_Def_Planifiee : DATETIME Code : VARCHAR(255) Id_Defourneuse : INT

<<Non- Identifying>>

<<Non-Identifying>> 1 0..*

0..*

GroupLoco Numero : BIGINT NumWagon : BIGINT 1 <<I d entifying>> 1..* 0..1 <<Identifying>> 0..*

Defournement_Cotherm Dh_Def : DATETIME Id_Four : INT V001 : INT V177 : INT

Locomotive NumLoco : BIGINT Numero : BIGINT NumWagon : BIGINT

Tender Tender : BIGINT Numero : BIGINT NumWagon : BIGINT

1 PdefListeResult

PdefEtat Etat : INT Libelle : VARCHAR(255) Signification : VARCHAR(255) 1 0..*

0..* Participer Id_Cycle : INT Dh_Def_Planifiee : DATETIME 0..* <<Identifying>> 1 Personne Id_Personne : INT Prenom : VARCHAR(255) Nom : VARCHAR(255) DateNaissance : DATETIME <<Non-Identifying>> 1 0..*

Id_Resultat : INT Dh_IdResultat : DATETIME Dh_Pause : DATETIME TypeDeModele : VARCHAR(255) NomMachineClient : VARCHAR(255) NomUser : VARCHAR(255) StatusExecutionModele : INT Dh_FinExecuteModele : DATETIME LibelleStatus_FinExecuteModele : VARCHAR(255) CommentaireResultat : VARCHAR(255) Dh_Def_Planifiee : DATETIME Etat : INT

<<Non-Identifying>>

<<Non-Identifying>> 1 0..*

PdefNombreFourProduit Dh_Pause : DATETIME NbreFourCopModelise : INT NbreFourKDModelise : INT NbreFourCopProgramme : INT NbreFourKDProgramme : INT NbreFourCopRealise : INT NbreFourKDRealise : INT Id_Resultat : INT

PlanningPoste Id_Cycle : INT Equipe : I NT Id_Person ne : IN T

10 - 29

Database Designer (Class Diag.)

(J) Iteration 5 : Transition Implementation

10 - 30

System Designer (Seq. Diag.)

(K) Iteration 1 : Elaboration Analysis
: quipe four : Dfourneuse : Guide_Coke : Coke_Car : Four 1. aligner(Four) 2. aligner(Four) 3. aligner(Four)
:: Defouneuse :3 E nfourneus eE Guide Coke

: E nfourneus eE 1
: Contremaitre

4. ouvrir( ) 4.1. ouvrir_four( ) 4.2. ouvrir_porte( )

D efournement_ Puissance

Defournement_ Cotherm

E nfournem ent Defournement_

ProfilCoke

P l anni ngD PlanningDefour efou r n nement ement

: Contrem aitre

1: 1: enregistrementPuissance() en fournem entE 3()

2: enregistrementTemperatureCotherm()

4.3. dfourner( ) 4.3. 1. transfrer_saumon(Saumon) 4.3.1.1. prendre_profil(Saumon)

2: enfournem entE 1()

3: enregistrementProfilCoke()

3: validationE nfournem ent()

4.3.1.2. rcept ionner_mp(Saumon)

4: validationDefournement()

4.3.1.2.1. fermer( )

4.4. fermer_four( ) 4.5. fermer_porte( )

(L) Iteration 2 : Elaboration Design

10 - 31

System Designer (Seq Diag.)

(N) Iteration 2 : Construction Design
20: moyenneTempCotherm() 21: ecartTypeTempCotherm() 23: moyenneTempCotherm() 24: ecartTypeTempCotherm()
P defLis teRes ult : Utilis ateur 1: s tartM odeleP V () 2: enregis treP lanningP ropos e() 3: s tartM odeleLight() 4: enregis treP lanningP ropos e() P defRes u lt at P l anni ngDefour neme nt TCx Lis teS erieT em pP y rom etre TCx S erieTem p P y rom etre Rec apP aus eC o P roduit E nfour nem ent Defournem ent_ Cotherm Defou rnem ent_ P uis s anc e

5: enreg is t reP l anni ngV al ide () 6: s e tP l annin g

Enfournem ent RecapPauseCoProduit Defournement_Cotherm

7: im prim eP lan ning( )

8: s etRes ultat()

9: validationE nfournem ent()

15: encoderCahierElectronique()

TCxSerieTemp Pyrometre

19: cart eCotherm Batt erie() 22: carteCothermFour() 25: courbesTemperatureSaumon() 26: historiqueCourbesTemperatureSaumon() 27: checkCarneaux()

16: txUtilisationE3()

10: validationDefournem ent()

11: enc oderS erieTem pCx () 1 2: enre gis t rerTem pCx ()

13: validerS erie()

14: encoder Com ment aire( )

12: enregistrerTempCx() 18: getTempSerie()

28: cartePuissanceBatterie() 29: cartePuissanceFour() 30: evolution3DPic() 31: evolution3DPAD() 32: evol ut ion3DID() 33: evolut ionPuis sanceMoyenneBat terie() 34: picMoyDerniersDefournements() 35: nbreFoursCalesParMoisPuissanceMois() Defournement_ Puissance

15: enc oderCahierE lec tronique()

16: tx Utilis ationE 3()

17: his to riqueCx 5-22() 18: getTem pS erie()

19: c arteCotherm B atterie() 20: m oy enneTem pCotherm () 21: ec ar tTy peTem pCother m( )

TCxListeS erieTemp Pyrometre 11: encoderSerieTempCx() 13: validerSerie() 14: encoderCommentaire() 17: historiqueCx5-22()

22: c arteC ot herm F our () 23: m oy enneTem pCotherm () 24: ec artTy peTem pCotherm ()

: Uti lisat eur

25: c our bes Tem peratur eS aum on()

26 : h is toriqueCou rbes Te mperat ureS aum on( )

27: c hec k C arneaux ()

1: startModelePV() 3: startModeleLight() 8: setResultat() 9: validationEnfournement() 10: validationDefournement() 5: enregistrePl anni ngValide() 7: imprimePlanning()

28: c arteP ui s s anc eB at te rie()

29: c arteP uis s anc eF our()

30: evolution3DP ic ()

31: evolution3DP A D()

32: evolution3DID()

33 : e vol utionP ui ss anc eM oy en neB att erie( )

34: pic M oy Derniers Defournem ents ()

PlanningDefournement 6: setPlanning

PdefResultat

PdefList eResult

35: nbreF ours Cales P arM ois P uis s anc eM ois ()

2: enregist rePl anni ngPropose() 4: enregist rePl anni ngPropose()

(M) Iteration 1 : Construction Analysis

10 - 32

Interfaces graphiques

Syst. Architect (Impl. Diag)

(O) Iteration 1 : Construction Implementation

Interfaces pour ingnieur de gestion

Choix de la fonctionnalit

Interfaces pour contrematre

Choix de la fonctionnalit

Planification Entretiens

Rapport journalier

Comparaison de fours

Historique dfournements

Connexion

Rapport dfournement

Rapport entretien

Instantiates System.windows.forms

Contrle
Uses Uses Uses Uses Uses Uses Uses Uses

Gestionnaire des entretiens

Gestionnaire de graphiques

Gestionnaire de requtes daccs la base de donnes Uses

Gestionnaire de dtection et de diagnostic des problmes

Gestionnaire des accs scuriss

Uses

Instantiates Syncfusion.chart

Uses

Uses

Domain dependant storage

Problmes rencontrs sur les fours

Identifications

Donnes de dfournement

Entretiens

Base de donnes

10 - 33

Base de donnes SQL server

Network Architect (Imp. Diag)

(P) Iteration 2: Construction Deployment
Ingnieur de production Automate pyromtre et profilocoke situ sur guide-coke Automate ampremtre situ sur le moteur de la dfourneuse

Ingnieur de production Contrematre PC de lingnieur de production Identification Ingnieur de production

Contrematre PC du contrematre Identification contrematre

ADO.NET

VAX

Rseau ethernet

Machiniste

Un seul mme serveur physique

Application scurise Gestion des accs Base de donnes Terminal machiniste Machiniste

Base de donnes Serveur de lapplication de gestion des fours Serveur didentification Serveur de la base de donnes

Accs spcifique Accs spcifique contrematre Ingnieur de production

Gestion accs Gestion accs contrematre Ingnieur de production Serveur de lapplication du machiniste

10 - 34

Soft. Engineer (Code)

(Q) Iteration 1 : Transition Implementation

10 - 35

Web Engineer (Code)

(R) Iteration 2 : Transition Deployment Intranet Deployment of the identified application functionalities

10 - 36

Web Engineer (Code)

(S) Iteration 3 : Transition Deployment Web E-Commerce Deployment

10 - 37