Automated Modeling of Legacy Systems Using the UML

Size: px
Start display at page:

Download "Automated Modeling of Legacy Systems Using the UML"

Transcription

1 Automated Modeling of Legacy Systems Using the UML by Pan-Wei Ng Software Engineering Specialist Rational Software Singapore Poor documentation is one of the major challenges of supporting legacy systems; in many cases, the only available documentation is the source code itself. This article describes steps you can take to model a legacy system using the Unified Modeling Language (UML), taking into account language constructs and application-specific usage of these constructs. The resulting model can be used to produce useful documentation that abstracts flows and structural relationships. We will illustrate the concepts behind the modeling process, using COBOL as the language of the legacy system, and automate the modeling process using Rational Roseý and its Extensibility Interface, which are also described in this article. Supporting legacy systems is not easy. When an enhancement request or defect is reported, the support team must be able to quickly evaluate the potential impact and magnitude of the change, estimate the effort required, and prioritize the work involved. None of this is simple, because often the only existing documentation is buried within the source code, and a typical application might have several hundred source files, each containing several thousand lines of code. Knowledge of the internal workings of these systems is often in the hands of only a few people who, through experience, understand only part of each legacy system they work with. It is not unusual to come across legacy systems that no single person can fully describe. Many legacy systems were written using older programming languages, which lack support for good programming practices. Even though the limitations of the programming languages might have been overcome by good development principles, this seldom happened (or it happened inconsistently). When these

2 systems were developed, the software industry had yet to evolve good software development principles such as encapsulation, abstraction, modularity, and architecture. Even for legacy systems that used newer, objectoriented languages, such principles might have been misapplied. Consequently, the impact of a change is seldom restricted to a small set of files or routines. Support teams need to sift through many source files and available documentation to trace through the program flows. In addition, serious problems can arise because important business rules are often embedded within legacy systems. Failure to account for such rules when making a change can be disastrous. The more critical the legacy system is to the business, the greater the risk. Consequently, supporting legacy systems is extremely demanding and risky. Automated Modeling of Legacy Systems For all these reasons, it is very valuable to have a structured approach for systematically deriving useful documentation based on existing legacy source code -- an approach that takes language specifics into account and produces documentation that is understandable by many people. This article describes such an approach. This approach employs the UML notation system and a modeling process based on the Rational Unified Processý or RUPý product, both of which are well recognized by the object-oriented community. Using UML raises the abstraction level for the legacy system being modeled up from the language in which it was originally constructed. Furthermore, the use of object-oriented approaches for modeling legacy systems is highly beneficial from the design perspective. After all, shouldn't good software design principles be universal and not limited to object-oriented languages? Thus, the choice of the UML and the RUP implies a common representation, and a common approach to describing software systems, which are both understandable by the software community in general. Automation is important, because it is not economically feasible to manually analyze and extract useful information from the extensive amount of source code found in legacy systems. In fact, lack of automation might be the reason for inadequate documentation in the first place. Automation is not limited to code scanning, which typifies most attempts at understanding legacy code. Rather, automation refers to abstracting internal representation to make it useful for further manipulation, analysis, and visualization. The idea of modeling encompasses the concepts of internal representation with a variety of views. Moreover, automation demands explicit expression of source code analysis rules, which has the advantage of making code analysis consistent. A Fundamental Modeling Principle: The UML Collaboration The UML collaboration is a fundamental construct for relating design to requirements. It describes how participating elements interact with each other to produce some observable result of value to the client. It comprises a structural aspect that describes relationships between participating elements, and a dynamic aspect that describes the behavior of these elements.

3 A use-case realization is one kind of collaboration. Figure 1 shows an example of a use-case realization: an Actor initiating communication with a use case. The use case is a statement of responsibility that dictates what the system should do. The use-case realization describes how that responsibility is fulfilled. It does so by identifying participants -- in this case, classes -- and showing that they interact with one another to fulfill the stated responsibility. The concept of collaborations is common to UML and the RUP, which use different stereotypical participants. In use-case analysis, the stereotyped classes include boundary, control, and entity classes; in business modeling, stereotyped classes include business workers and business entities. The same concept can be borrowed and applied to different domains. For example, when modeling SQL scripts, the participants are stored procedures and database tables. When attempting to document a collaboration, it is important to work at an appropriate level of abstraction to avoid unnecessary complexity. For example, when you do business modeling, you should not be dealing with Java classes. Figure 1: UML Collaboration In this article, we will describe abstract flows as collaborations based on existing source code. Without abstraction, the resulting documentation would simply mirror existing source code and fail to provide an accurate overview of the legacy system. Consequently, it is important to formulate abstraction rules that identify significant elements in the given source. Steps for Modeling Legacy Systems Using the UML This section describes steps for modeling legacy systems, which are made up of a number of programs, each fulfilling some system functionality. One or more source files implements each program through a programming language. In modeling a legacy system, it is important to understand both programming language constructs, and the programming style (i.e., the way the language is used) because both language and program-specific constructs are necessary to

4 abstract the program, as depicted in Figure 2. Figure 2: Legacy System Structure and Abstraction Because legacy systems may be developed using multiple languages, the specifics of each language must be taken into account. This implies that, for each language used in the legacy system, we must perform the following steps: 1. Identify significant language constructs (i.e., language constructs that are useful in abstracting flows in a source file and understanding relationships between elements). 2. Describe language grammar. 3. Map language grammar elements to UML elements. 4. Identify views of the UML elements that abstract program structure and flows. Once the language specifics have been handled, each program in the legacy system can be analyzed individually. This implies that for each program, we must take the following additional steps: 5. Identify language usage in the legacy program, including abstraction rules that are useful in abstracting program flows. 6. Organize the model of the legacy program. 7. Document the model. Our approach distinguishes general language aspects from program-specific aspects, and our goal is to: Automate as much as possible the general language parts that are reusable across programs implemented in that language. Identify guidelines to support the program-specific portions. General Language Aspects This section describes how the general language aspects of modeling legacy systems are taken into account. The steps in this section have to be repeated once per implementation language. Step One: Identify Significant Language Constructs

5 This first step examines significant language constructs to identify those that are useful in abstracting flows within a program. The significant language constructs for COBOL, along with explanations of their significance, are listed in Table 1. Table 1: COBOL Significant Language Constructs Significant Language Construct COBOL Program COBOL Working Storage Sections COBOL Paragraph COBOL Statements COBOL Perform Statements COBOL Conditional Statements Embedded SQL Statements Explanation This is the physical unit of the legacy system to be modeled. The legacy system is analyzed by analyzing each program individually. This represents the information that is manipulated by the program. This represents the decomposition of the COBOL program. This represents each step in the flow of the COBOL program and is the next level decomposition of the COBOL paragraph. This describes the flow within the COBOL program by relating different COBOL paragraphs to each other. This represents decisions described in the program: they are often a physical implementation of some business or technical rules. These describe database transactions. SQL statements can be used to identify database structures (i.e., tables and columns) that are usually poorly documented. Step Two: Describe Language Grammar A language grammar is a formal representation of language constructs. Grammars for legacy systems tend to be much more complicated than those of newer languages such as Java and C#. One challenge is to define a good grammar for the target language. Distinguishing which language constructs are significant, as we did in the previous step, permits us to ignore the unimportant aspects of the grammar and consequently simplifies this step. COBOL files often have characters before the seventh column, and after the seventy-second column of each source line, which are mingled with the actual source. These characters are unimportant, so we can have a preprocessor discard them -- which is a lot simpler than dealing with them within the parser. Step Three: Map Language Grammar Elements to UML Elements In this step, we will map language grammar elements to stereotyped UML

6 elements. When defining this mapping, it is important to ensure that there is a one-to-one correspondence to avoid confusion. As there are embedded SQL statements in the source code that can give clues to dependencies in SQL tables, we will map both COBOL and SQL language constructs to UML. Mapping COBOL to UML. A possible mapping from COBOL to UML is summarized in Table 2. The first column identifies the grammar element; the second column provides the UML mapping and its corresponding stereotype where applicable; and the third column gives the reason for the mapping. Table 2: COBOL Language Grammar Mapping to UML No Grammar Element UML Mapping Reason 1 Program component <<program>> This is the physical implementation of the program design. 2 Program class <<program>> This is the design of the program. 3 Program use case Because each program is written to fulfill some system functionality, it can be mapped to a use case. 4 Program use-case realization The realization of the program purpose is in the program itself. 5 Record Description nested class stereotyped <<record>> or attribute If the record description has an associated PIC declaration, it is an attribute; otherwise, it is a nested class belonging to the program. See Figure 3. 6 Paragraph private operation Each paragraph is a collection of steps that is not callable by another program. 7 Statement activity Each statement is a step within a paragraph. 8 Perform Statement 9 Perform Statement 10 Conditional Statement activity <<perform>> reflexive message decision <<condition>> This is a type of statement. This is a perform statement that calls another paragraph in the program. This is a type of statement.

7 Figure 3: UML Mapping of COBOL Record Descriptions Mapping Embedded SQL to UML. SQL statements are mapped into dependencies in class diagrams and stereotyped according to the type of SQL operation, such as select, insert, delete, update, create, and so on. Although it is possible to stereotype the dependencies as read, write, or read/write, the SQL operations designations are more meaningful. Furthermore, the types of SQL statements are limited and consequently do not clutter the class diagrams. Our proposed mapping from embedded SQL to UML is summarized in Table 3. Table 3: Embedded SQL Language Grammar Mapping to UML No Grammar Element UML Mapping Reason 1 SQL Table Clause class <<table>> A "FROM" clause in an embedded SQL statement indicates the presence of a table in some database. 2 SQL Statement message A running COBOL program sends messages to records of some SQL tables; that is, it sends a message to a record. 3 SQL Select Statement 4 SQL Insert Statement dependency <<select>> dependency <<insert>> The select statement implies that the COBOL program is referencing a table; it does not modify the contents of the table. The insert statement implies that the COBOL program is referencing a table, and it modifies the contents of the table. Stereotypes are also defined for <<update>>, <<create>>, and similar statements. 5 SQL Field Clause attribute Table fields (attributes) can be extracted from SQL statements. Step Four: Identify Views of UML Elements

8 This step defines views that abstract structural relationships and program flows. Several possible views, along with justifications for them, are listed in Table 4. We will see examples of these views in the next section after we introduce program-specific aspects. The views are generated automatically by a Rose COBOL Add-In, which we will describe in greater detail later on. Table 4: Views of UML Elements Mapped from Language Grammar View Diagram Type Justification View of Participating Tables View of Participating Classes SQL Table Manipulation class diagram class diagram This view presents the SQL tables that are manipulated by the program (see Figure 4). This view presents the structure of the COBOL program and its constituent record descriptions, which are stereotyped as <<program>> and <<record>> respectively (see Figure 5). sequence diagram This view describes how the COBOL program manipulates the database (see Figure 6). Program Flow activity diagram This view describes the flow within a paragraph in the COBOL program (see Figure 7). Note that program flows for COBOL are represented in an activity diagram rather than a sequence diagram. Because there are no classes and objects in COBOL, a sequence diagram would contain only a single column; it would be visually unappealing and not very useful. Activity diagrams, on the other hand, are visually similar to flow charts, which are familiar to COBOL developers. In addition, you can add swimlanes, which are useful in subsequent refactoring. Each swimlane represents a COBOL file, and can be used to evaluate the impact of delegating flows to COBOL files. Step Five: Identify Language Usage In addition to the language-related steps we described above, it is necessary to identify program-specific styles and guidelines when analyzing legacy systems. Identify Abstraction Rules. Each development organization has specific guidelines for developing software and for the use of language constructs that can be exploited to abstract program flows. For example, an organization standard might dictate that: Remarks for each paragraph are placed after the paragraph name.

9 Remarks for each SQL statement are placed before the SQL statement. Note that these standards are not always adhered to, so there is always some tidying up required. Earlier, we discussed the significant effort that is sometimes required to derive a robust grammar. One possible way to make this easier is to introduce preprocessing that discards unnecessary elements in the grammar. The example we mentioned above was discarding characters in a COBOL program that appear before the seventh column and after the seventy-second column, which are skipped by the COBOL compiler. Identifying Abstraction Rules for COBOL Programs. A typical COBOL program contains a large number of record descriptions, paragraphs, and embedded SQL statements. We need to identify which of these are crucial to the understanding of the program by employing the rules listed in Table 5. Table 5: Abstraction Rules for COBOL Programs Main Paragraph Significant Parts Main Subordinate Paragraphs Paragraphs with Embedded SQL Statements Record Descriptions in an SQL Statement Justification This is the first paragraph called when the program executes. It calls other paragraphs and normally provides a good overview of the program. In our case, this paragraph is labeled as 0000-MAIN. These are the immediate paragraphs called by the main paragraph. These paragraphs are significant because they invoke database transactions. Record descriptions (attributes) found in SQL statements are significant because of their relationship with the SQL tables. The rules listed in Table 5 are only a starting point and are at best guidelines; exceptions are frequent. Human intervention is required to decide if a specific paragraph or record description is truly significant. Step Six: Organize the Model Once we have mapped the constructs and parts of a COBOL program into UML, we need to decide where to place them in a model, and how the significant parts will be documented through appropriate views. We can use the design model organization listed in Table 6. Table 6: Design Model Organization

10 Design Model COBOL Package Table Package Justification This package holds the COBOL program as a class stereotyped <<program>>. This package holds all tables extracted from SQL tables, and is useful in understanding the schema of the relational database referenced by the COBOL program. Use-Case Realization Package This package holds the diagrams describing significant aspects of the COBOL program. These diagrams will be treated as important views below and are illustrated in Figures 4 through 7. Step Seven: Document the Model Having defined the mapping from the given legacy language to UML, and the mapping from the given COBOL program to a design model organization, we can now start to document the modeling results. The document is expressed in terms of views to the model: View of participating tables View of participating classes SQL table interaction Program flow These views are described in the following subsections. View of Participating Tables. Figure 4 shows an example View of Participating Tables, which depicts the static relationships between the COBOL program and the SQL tables. Each type of access is stereotyped according to the SQL clause through which the COBOL program manipulates the table. Tables can be manipulated in many ways; consequently, a table can have multiple dependencies, each with a different stereotype.

11 Figure 4: View of Participating Tables View of Participating Classes. Figure 5 shows an example View of Participating Classes, depicting the static relationships between the COBOL program and its record descriptions. If we attempt to map this with the analysis classes in the RUP, then the COBOL program will play the role of both a boundary class and a control class in a use-case realization. The record description classes will play the role of entity classes. This analogy will be useful when attempting to refactor the COBOL program. In Figure 5, the stereotype <<significant>> is based on the rules identified in Table 5. Figure 5: View of Participating Classes

12 SQL Table Interaction View. Figure 6 is an example of an SQL Table Interaction diagram. It describes sequentially how the COBOL program makes the transaction. If failure modes have to be documented, they will appear as separate SQL table interaction diagrams. Each message in the sequence diagram has a name equivalent to the SQL clause. The detail of each message is in its description and consequently not shown in Figure 6. Figure 6: SQL Table Interaction Diagram Program Flow View. Figure 7 shows an example Program Flow View. It is an activity diagram describing the conditional logic within a paragraph. Such diagrams are useful for describing both business logic and transactional logic.

13 Figure 7: Program Flow View Note that conditions in Figure 7 are represented as states stereotyped as <<Condition>> rather than as decisions, which we saw in Table 2. Our Rose COBOL Add-In uses a UML activity instead. Automated Modeling Rather than manually abstracting program structure and flows from source code, it is better to have a tool that automatically generates the "first cut" and allows the generated model to be manipulated. This section discusses how to achieve automation as well as the additional benefits of automation for supporting legacy systems. It also discusses the requirements and design of such an automated tool. Requirements The requirements of an automated modeling tool are summarized as a usecase model in Figure 8, in which the Actors are members of a support team consisting of the developer, IT manager, maintenance team, and architect. Figure 8: Actors and Use Cases For Automated Modeling Tool Table 7 describes the use cases in this model. Table 7: Use Cases for Automated Modeling Tool

14 No Use Case Description 1 Manage Legacy Model Create and update the legacy model. 2 Document Legacy System Reverse engineer existing COBOL source and produce Word documents. 3 Analyze Impact of Change Trace one part of the reverse-engineered model to another, including queries searching for impacted UML elements. 4 Make Source Code Changes The maintenance team makes changes, which must be synchronized to the reverse-engineered model. 5 Review Changes The manager reviews changes to the source code or model to ensure that only relevant portions are modified. 6 Refactor Architecture -The architect might reorganize the model to improve resiliency. Elements of the new model must trace to the existing one. -Automatic refactoring rules might be defined to generate the new model. The use cases outlined in Table 7 have a much larger scope than merely modeling legacy code. This is because we do not model a legacy system for the sake of documenting it, but to maintain and upgrade it. We can partially implement the use cases for the automated modeling tool through our Rose COBOL Add-In and related Rational tools, as follows. Manage Legacy Model Use Case: an inherent capability of Rose. Document Legacy System Use Case: fulfilled by our Rose COBOL Add- In, which abstracts the legacy system in a Rose model, and also by Rational SoDA, which walks through the Rose model and generates appropriate reports. Analyze Impact of Change Use Case: fulfilled by the Rose COBOL Add-In as it captures the relationships between elements within the Rose model and presents them through appropriate views (described above). Review Changes Use Case: fulfilled by allowing the user to hyperlink to the source code from the model. Although a "Refactor Architecture" use case would be very beneficial, identifying and codifying refactoring rules is not simple, so we will leave this to future research. However, having a UML model of the legacy system allows us to perform refactoring with UML rather than COBOL. By operating at a higher level of abstraction and in a language-independent environment (in UML), the refactoring rules can be made generic and not limited to COBOL. Structure of the Automated Modeling Tool

15 An overview of the structure elements in our Automated Modeling Tool is depicted in Figure 9 as a class diagram. This figure can be viewed as a generic structure for automating the modeling steps discussed earlier and can be applied to systems implemented by any language. Figure 9: Structure of the Automated Modeling Tool The elements in Figure 9 are stereotyped as entities, which represent information, and controllers, which manipulate the information. Entities are denoted by the entity class stereotypes; controllers are denoted by control class stereotypes. Every entity in this figure contains a number of elements. For example, the legacy source code contains characters; the UML representation contains many UML elements mapped from the source code. The notes in this figure describe the mapping rules used to relate adjacent entities. The entities are described in Table 8. Note that the refactoring mechanism has not yet been implemented. Table 8: Structural Elements

16 No Architectural Entities Description 1 Original Legacy Source This represents the existing source code. 2 Cleaned Legacy Source This is generated by running the original source code through a preprocessor. Existing source code may be preformatted with additional characters outside the standard COBOL constructs. 3 UML Representation This is the UML representation of the legacy source, which is generated by running the cleaned legacy code through a parser. 4 Rose Representation Because of Rose's internal architecture, the UML representation is not directly consumable by Rational Rose and has to be mapped to a Rose representation. In addition, the Rose modeller insulates changes in the Rose code base. A separate instance of the Rose representation is generated by a refactoring mechanism. 5 Documentation of Legacy Code This is the document extracted from the Rose representation by Rational SoDA. 6 Other Language Representation The refactored Rose representation can be used to forward generate code in another language through other Rose language add-ins, such as Java and VB. Implementation The UML diagrams in Figures 4-7 were generated with the Rose COBOL Add-In. Dragging the preprocessed COBOL source into any class diagram in Rose will perform the automated modeling. This will generate several packages and diagrams, as depicted in Figure 10.

17 Click to enlarge Figure 10: Rose Screen Showing Generated COBOL Packages In the logical view, three packages are created: A COBOL package containing COBOL source. A tables package containing the SQL tables accessed. A use-case realization package containing several views described earlier. The Rose COBOL Add-In also supports a traceability capability. The user can right click on a COBOL operation or activity and select Browse. The Add-In will load the COBOL file and highlight the code from which the UML classifier is mapped. For example, Figure 11 is produced by the Add-In when you right click on one of the activities shown in Figure 7. This feature is useful to check whether the mapping is correct.

18 Figure 11: Tracing UML Mapping to Legacy Source Code Evaluating the Legacy Model Now that we have automatically generated a visual model, we want to establish how accurately it reflects the given legacy system. Our model was produced through a set of transformations shown in Figure 10; consequently, the quality of our model can be evaluated by examining these transformations and asking questions such as the following. Consistency: Is the modeling process repeatable and reversible? At every stage in the modeling process, can we reconstruct the previous stage? Consistency demands a bidirectional relationship between the entities shown in Figure 9. For example, if a COBOL program is mapped to a UML class stereotyped <<program>>, then the converse must be valid. Completeness: Have we considered every factor during the transformation? The modeling process is complete if no information is lost during the modeling process. Completeness demands that every element in one entity must be mapped to another element in the next stage. Consistency and completeness are properties of the mapping rules between adjacent entities. Consequently, the goal of any modeling process is to define good mapping rules. Once these properties are achieved, it is possible to synchronize the contents of the source code and the UML model. Figure 12 illustrates the concepts of consistency and completeness. It shows a mapping that is not fully complete and consistent because Source Element 4 is not mapped to anything (i.e., not complete), and the mapping from Source Element 3 to UML Element 3 is unidirectional (i.e., not consistent). However,

19 the mapping between both entities is consistent and complete with respect to the significant elements. Figure 12: Consistency and Completeness of Modeling Process: Example of Incomplete Mapping It is very difficult -- and it requires too much detail -- to establish a fully complete and consistent modeling process. Instead, we focus on the significant elements and on achieving completeness with respect to those elements. The modeling process described in this article is founded on this principle, and it also distinguishes significant elements that are language specific and program/organization specific. Further Development In this article, we have discussed the steps necessary to construct a visual model of a legacy system and how to automate those steps. Ours is a UML model, physically stored using Rose's internal representation. We demonstrated the validity of this approach through the implementation of our Rose COBOL Add-In, and then evaluated the modeling process in terms of consistency and completeness. Continuation of this work will depend very much on customer needs and requests. In fact, I developed the Rose COBOL Add-In for a customer who had numerous COBOL applications that were sparsely documented. The customer was a large organization that also intended to adopt the RUP and UML, so the notion of having existing COBOL applications documented in UML was very attractive. The support team would also be trained in UML, and the documentation would be aligned with that in the RUP, for example, as usecase realizations (Figures 4-7 show how this can be achieved). There is strong interest from other potential clients who have seen demonstrations of the Rose COBOL Add-In, because they recognize the universality of the modeling approach and the advantages of UML. I have also received requests to abstract program flows developed in other languages, including some for poorly documented systems developed in Java. Based on the same principles discussed in this article, my teammates and I developed a separate Rose add-in to automatically generate sequence diagrams from Java code (i.e., a Rose Java Add-In). To do this, we identified abstraction rules to simplify an otherwise very complicated sequence diagram. In addition, the Rose Java Add-In has a complexity indicator for each operation. Developers need to examine only the operations with high indicators. In another case, a client had a large application comprising 200+ collaborating executables (EXEs) and dynamic link libraries (DLLs) developed

20 in Visual Basic 5 and Delphi. In this case, the significant elements were EXEs and DLLs rather than source code. Given the increasing interest in the UML and RUP within the software community, it is reasonable to expect that demands for automatic modeling of legacy systems will continue to grow. Although the automatic generation of a UML model solves only part of the challenges faced by support teams, it is an important part. In addition, an automated modeling tool can facilitate several other tasks, such as: Synchronizing the model against code changes. Reviewing code changes. Refactoring the legacy model and transforming it into another implementation language. Clearly, more exploration and feedback are required, especially in the areas of formulating abstraction rules, identifying useful viewpoints into the model, and identifying refactoring rules. Identifying and structuring these rules will be the basis for subsequent enhancements. For more information on the products or services discussed in this article, please click here and follow the instructions provided. Thank you! Copyright Rational Software 2002 Privacy/Legal Information

Business Process Modeling and Simulation with UML

Business Process Modeling and Simulation with UML Business Process Modeling and Simulation with UML Part I: Defining a UML Transaction Model That Maps to RUP Business Models by Pan-Wei Ng Software Engineering Specialist Rational Software Singapore Business

More information

Robust Object Oriented System Analysis

Robust Object Oriented System Analysis Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.

More information

Rational Unified Process for Systems Engineering. Part II: System architecture

Rational Unified Process for Systems Engineering. Part II: System architecture Copyright Rational Software 2003 http://www.therationaledge.com/content/sep_03/m_systemarch_mc.jsp Rational Unified Process for Systems Engineering Part II: System architecture by Murray Cantor Principal

More information

Business Process Modeling and Simulation with UML

Business Process Modeling and Simulation with UML Business Process Modeling and Simulation with UML Part II: Executing a UML Transaction Model with Rational Rose by Pan-Wei Ng Software Engineering Specialist Rational Software Singapore Business modeling

More information

Introduction to Business Modeling Using the Unified Modeling Language (UML)

Introduction to Business Modeling Using the Unified Modeling Language (UML) Introduction to Business Modeling Using the Unified Modeling Language (UML) by Jim Heumann Requirements Management Evangelist Rational Software At a time when businesses are becoming more and more automated

More information

IT3102: OBJECT ORIENTED SYSTEMS DEVELOPMENT

IT3102: OBJECT ORIENTED SYSTEMS DEVELOPMENT : OBJECT ORIENTED SYSTEMS DEVELOPMENT 1. OUTLINE OF THE SYLLABUS (Compulsory) Topic Minimum number of hours Object Oriented Concepts 02 Visual Modelling using Unified Modelling Language (UML) Introduction

More information

Lecture 5: Software Design

Lecture 5: Software Design Software Engineering Lecture 5: Software Design Introduction to software design Decomposition and modularity Architectural styles and strategies Issues in design creation Characteristics of a good design

More information

User experience storyboards: Building better UIs with RUP, UML, and use cases

User experience storyboards: Building better UIs with RUP, UML, and use cases Copyright Rational Software 2003 http://www.therationaledge.com/content/nov_03/f_usability_jh.jsp User experience storyboards: Building better UIs with RUP, UML, and use cases by Jim Heumann Requirements

More information

The Role of Functional Prototyping in the Development Process

The Role of Functional Prototyping in the Development Process The Role of Functional Prototyping in the Development Process by Jim Conallen Editor's Note: Each month, we will feature one or two articles from the Rational Developer Network, just to give you a sense

More information

Structuring Design Deliverables with UML

Structuring Design Deliverables with UML Structuring Design Deliverables with UML Pavel Hruby Navision Software a/s Frydenlunds Allé 6 +45 45 65 50 00 +45 45 65 50 01 ph@navision.com Abstract The idea of using Unified ing Language (UML) appeals

More information

Applying the Rational Unified Process: A Web Service Sample

Applying the Rational Unified Process: A Web Service Sample Applying the Unified Process: A Web Service Sample The Unified Process (RUP) is a disciplined approach to engineering a piece of software. In this article, we ll walk through using the RUP and related

More information

UML: Abstraction as a Criterion for Defining Class Diagrams and Object Diagrams

UML: Abstraction as a Criterion for Defining Class Diagrams and Object Diagrams UML: Abstraction as a Criterion for Defining Class Diagrams and Object Diagrams Ivan Pogarcic 1, Miro Francic 1 and Vlatka Davidovic 1 1 Business Dept, Study of Information Systems, Polytechnic of Rijeka

More information

Object-Oriented Design Metrics Using UML Class Diagrams Albert Dieter Ritzhaupt 3441 West Turkey Oaks Drive Jacksonville, FL (904)

Object-Oriented Design Metrics Using UML Class Diagrams Albert Dieter Ritzhaupt 3441 West Turkey Oaks Drive Jacksonville, FL (904) Object-Oriented Design Metrics Using UML Class Diagrams Albert Dieter Ritzhaupt 3441 West Turkey Oaks Drive Jacksonville, FL 32277 (904) 859-9799 rita0001@unf.edu ABSTRACT In this paper, a brief survey

More information

Sample Bank ATM Use-Case Modeling Guidelines Version 1.0

Sample Bank ATM Use-Case Modeling Guidelines Version 1.0 Sample Bank ATM Use-Case Modeling Guidelines Version 1.0 Table of Contents 1. Document Control Information 3 1.1 Revision History 3 1.2 Reviewers and Approvers 3 2. Introduction 4 2.1 Purpose 4 2.2 References

More information

The Role of Requirements Traceability in System Development

The Role of Requirements Traceability in System Development The Role of Requirements Traceability in System Development by Dean Leffingwell Software Entrepreneur and Former Rational Software Executive Don Widrig Independent Technical Writer and Consultant In the

More information

RUP Design Workflow. Michael Fourman Cs2 Software Engineering

RUP Design Workflow. Michael Fourman Cs2 Software Engineering RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Model Driven Legacy Migration

Model Driven Legacy Migration Driven Legacy Migration Patrick DJ Kulandaisamy (patrickj@infosys.com) Comfactory, SETLabs Infosys Technologies Limited, Bangalore, India Abstract Most enterprises depend on information technology to execute

More information

THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS

THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS THE EVOLVING ROLE OF DATABASE IN OBJECT SYSTEMS William Kent Database Technology Department Hewlett-Packard Laboratories Palo Alto, California kent@hpl.hp.com 1990 CONTENTS: ABSTRACT 1 INTRODUCTION...

More information

Applying the Rational Unified Process: A Web Service Sample

Applying the Rational Unified Process: A Web Service Sample Applying the Unified Process: A Web Service Sample The Unified Process (RUP) is a disciplined approach to engineering a piece of software. In this article, we ll walk through using the RUP and related

More information

Chapter 4 An Introduction to the J2EE Developer Roadmap

Chapter 4 An Introduction to the J2EE Developer Roadmap ch04_51-60.qxd 7/18/02 11:23 AM Page 51 Chapter 4 An Introduction to the J2EE Developer Roadmap In this chapter we introduce the J2EE Developer Roadmap. As we described in Chapter 3, An Introduction to

More information

An Introduction to IDIOM Architecture

An Introduction to IDIOM Architecture IDIOM An Introduction to IDIOM Architecture Introduction The normal practice for implementing business rules is to encode the business rules within the application using the same programming language as

More information

Implementation Workflow

Implementation Workflow Implementation Workflow Michael Fourman Introduction Implement the design in terms of components source code, scripts, binaries, executables, etc. Flesh out the architecture Plan system integrations in

More information

Business Modeling with UML

Business Modeling with UML Business Modeling with UML Hans-Erik Eriksson and Magnus Penker, Open Training Hans-Erik In order to keep up and be competitive, all companies Ericsson is and enterprises must assess the quality of their

More information

Name of pattern types 1 Process control patterns 2 Logic architectural patterns 3 Organizational patterns 4 Analytic patterns 5 Design patterns 6

Name of pattern types 1 Process control patterns 2 Logic architectural patterns 3 Organizational patterns 4 Analytic patterns 5 Design patterns 6 The Researches on Unified Pattern of Information System Deng Zhonghua,Guo Liang,Xia Yanping School of Information Management, Wuhan University Wuhan, Hubei, China 430072 Abstract: This paper discusses

More information

Software Requirements Specification. Version <1.0>

<Team Name> <Project Name> Software Requirements Specification. Version <1.0> Version [Note: The following template is provided for use with the Rational Unified Process] [Text enclosed in square brackets and displayed in blue italics (style=infoblue)

More information

Modeling the Enterprise Data Architecture

Modeling the Enterprise Data Architecture Copyright Rational Software 2003 http://www.therationaledge.com/content/feb_03/t_modelarchitect_aj.jsp Modeling the Enterprise Data Architecture by Andrew K. Johnston Independent Consultant and Richard

More information

Simplified view of a subsystem. The what, why, and how of a subsystem. by Fredrik Ferm Software Engineering Specialist

Simplified view of a subsystem. The what, why, and how of a subsystem. by Fredrik Ferm Software Engineering Specialist Copyright Rational Software 2003 http://www.therationaledge.com/content/jun_03/t_subsystem_ff.jsp The what, why, and how of a subsystem by Fredrik Ferm Software Engineering Specialist Rational Software,

More information

Rose/Architect: a tool to visualize architecture

Rose/Architect: a tool to visualize architecture Published in the Proceedings of the 32 nd Annual Hawaii International Conference on Systems Sciences (HICSS 99) Rose/Architect: a tool to visualize architecture Alexander Egyed University of Southern California

More information

Chapter 2 Data Models

Chapter 2 Data Models 11e Database Systems Design, Implementation, and Management Chapter 2 Data Models Learning Objectives In this chapter, you will learn: About data modeling and why data models are important About the basic

More information

Chapter 7: Object Oriented System Analysis And Design

Chapter 7: Object Oriented System Analysis And Design Chapter 7: Object Oriented System Analysis And Design Object-oriented analysis and design (OOAD) Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a

More information

OBJECT-ORIENTED ANALYSIS AND DESIGN

OBJECT-ORIENTED ANALYSIS AND DESIGN OBJECT-ORIENTED ANALYSIS AND DESIGN Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity

More information

Unified Modeling Language (UML) for Database Systems and Computer Applications

Unified Modeling Language (UML) for Database Systems and Computer Applications Unified Modeling Language (UML) for Database Systems and Computer Applications Sunguk Lee * Research Institute of Industrial Science and Technology Pohang, Korea sunguk@rist.re.kr *Correspondent Author:

More information

Find lasting success with process management

Find lasting success with process management Find lasting success with process management process4.biz Successful businesses have their processes under control: They are distinguished by a high level of maturity in business process automation, which

More information

An object is a combination of data and logic; the representation of some real-world entity.

An object is a combination of data and logic; the representation of some real-world entity. UNIT I PART - A 1. What is an object? An object is a combination of data and logic; the representation of some real-world entity. 2. What is the main advantage of object-oriented development? High level

More information

CHAPTER 13 OBJECT-ORIENTED ANALYSIS

CHAPTER 13 OBJECT-ORIENTED ANALYSIS Lecture Software Engineering CHAPTER 13 OBJECT-ORIENTED ANALYSIS Lecture Software Engineering Topics Introduction The Analysis Workflow Extracting the Entity Classes Object-Oriented Analysis: The Elevator

More information

Copyright 2003 New Technology / enterprise Limited -

Copyright 2003 New Technology / enterprise Limited - Copyright 2003 New Technology / enterprise Limited - www.jeewiz.com Introduction The Rational Unified Process is the Rational Corporation s version of Unified Process Development. RUP, as it is usually

More information

Assuming the Role of Systems Analyst & Analysis Alternatives

Assuming the Role of Systems Analyst & Analysis Alternatives Assuming the Role of Systems Analyst & Analysis Alternatives Nature of Analysis Systems analysis and design is a systematic approach to identifying problems, opportunities, and objectives; analyzing the

More information

The role of integrated requirements management in software delivery.

The role of integrated requirements management in software delivery. Software development White paper October 2007 The role of integrated requirements Jim Heumann, requirements evangelist, IBM Rational 2 Contents 2 Introduction 2 What is integrated requirements management?

More information

Objectives of Design. Chapter 4. Product Design. Product Design versus Class Design. Product Design Overview. Object Persistence

Objectives of Design. Chapter 4. Product Design. Product Design versus Class Design. Product Design Overview. Object Persistence Objectives of Design Chapter 4 Product Design As all other aspects of object-oriented system development, design can be deployed in an iterative or top-down development context The design phase takes the

More information

Object Oriented Analysis and Design with UML and RUP

Object Oriented Analysis and Design with UML and RUP Object Oriented Analysis and Design with UML and RUP Course Length: 5 Days Course Code: JAVA1136 Course Description Learn how to use object-oriented techniques from requirements gathering to implementation.

More information

The Use Case Model. Chapter. System Behavior. Actors. Use Cases. Use Case Diagrams. Activity Diagrams. Summary

The Use Case Model. Chapter. System Behavior. Actors. Use Cases. Use Case Diagrams. Activity Diagrams. Summary Quatrani.book Page 21 Monday, May 8, 2006 11:56 AM Chapter The Use Case Model System Behavior Actors Use Cases Use Case Diagrams Activity Diagrams Summary 21 Quatrani.book Page 22 Monday, May 8, 2006 11:56

More information

Abstraction and Information Hiding

Abstraction and Information Hiding Chapter 1: Programming Principles Object Oriented Analysis and Design Abstraction and information hiding Object oriented programming principles Unified Modeling Language Software life-cycle models Key

More information

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas

1-04-10 Configuration Management: An Object-Based Method Barbara Dumas 1-04-10 Configuration Management: An Object-Based Method Barbara Dumas Payoff Configuration management (CM) helps an organization maintain an inventory of its software assets. In traditional CM systems,

More information

Road to a Resilient Architecture

Road to a Resilient Architecture Jacobson_Ch11.fm Page 167 Wednesday, December 8, 2004 4:10 PM 11 Road to a Resilient Architecture The single most important determinant of the quality of a software system is its architecture. A good architecture

More information

Overview. The Rational Unified Process. Reference. Why Model? Sample Models. Well-Known Models in Software. A Brief Introduction

Overview. The Rational Unified Process. Reference. Why Model? Sample Models. Well-Known Models in Software. A Brief Introduction Overview The Rational Unified Process A Brief Introduction Reasons/history of software development process models Rational Unified Process Overview Phases and workflows Terminology Example iteration Reference

More information

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology?

In this Lecture you will Learn: Systems Development Methodologies. Why Methodology? Why Methodology? In this Lecture you will Learn: Systems Development Methodologies What a systems development methodology is Why methodologies are used The need for different methodologies The main features of one methodology

More information

Business Process Modeling with Structured Scenarios

Business Process Modeling with Structured Scenarios Business Process Modeling with Structured Scenarios Doug Rosenberg ICONIX Software Engineering, Inc. In 2008, based on our experience with a number of business process engineering projects over the last

More information

Graphical Object-Oriented Programming In LabVIEW Jörgen Jehander

Graphical Object-Oriented Programming In LabVIEW Jörgen Jehander Application Note 143 Graphical Object-Oriented Programming In LabVIEW Jörgen Jehander Introduction www.endevo.se A problem today in too many LabVIEW programs is that they are expensive to maintain. Fixing

More information

SOA Enabled Workflow Modernization

SOA Enabled Workflow Modernization Abstract Vitaly Khusidman Workflow Modernization is a case of Architecture Driven Modernization (ADM) and follows ADM Horseshoe Lifecycle. This paper explains how workflow modernization fits into the ADM

More information

Problem Analysis : Concepts and Techniques

Problem Analysis : Concepts and Techniques 4 Problem Analysis : Concepts and Techniques Problem Analysis Definition: the process of understanding the real-world problems and users needs and proposing abstract solutions to those problems. Goal:

More information

iagile: A Tool for Database Generation Guided by Graphical User Interface

iagile: A Tool for Database Generation Guided by Graphical User Interface www.ijcsi.org 292 iagile: A Tool for Database Generation Guided by Graphical User Interface Shaimaa Galal 1 and Ehab Hassanein 2 1 Information systems department, Cairo university Cairo, Egypt 2 Information

More information

Modeling Use Cases with the Borland Suite of Tools

Modeling Use Cases with the Borland Suite of Tools Modeling Use Cases with the Borland Suite of Tools By Serge Charbonneau, Principal Consultant for Xelaration Software Corporation (www.xelaration.com) Introduction Use case modeling is a widely used technique

More information

Parsing Technology and its role in Legacy Modernization. A Metaware White Paper

Parsing Technology and its role in Legacy Modernization. A Metaware White Paper Parsing Technology and its role in Legacy Modernization A Metaware White Paper 1 INTRODUCTION In the two last decades there has been an explosion of interest in software tools that can automate key tasks

More information

WHAT MOTIVATED DATA MINING? WHY IS IT IMPORTANT?

WHAT MOTIVATED DATA MINING? WHY IS IT IMPORTANT? WHAT MOTIVATED DATA MINING? WHY IS IT IMPORTANT? Data mining is mainly used for decision making in business. The abundance of data, coupled with the need for powerful data analysis tools, has been described

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

Chapter 10 Object-Oriented Design: Principles

Chapter 10 Object-Oriented Design: Principles Systems Analysis and Design in a Changing World, sixth edition 10-1 Chapter 10 Object-Oriented Design: Principles Table of Contents Chapter Overview Learning Objectives Chapter Overview In the earlier

More information

Software architecture is a representation that enables a software engineer to

Software architecture is a representation that enables a software engineer to CHAPTER 10 ARCHITECTURAL DESIGN Overview Architectural design represents the structure of the data and program components required to build a computer-based system. A number of architectural "styles" exist.

More information

The Rational Unified Process

The Rational Unified Process The Rational Unified Process A Brief Introduction Overview Reasons/history of software development process models Rational Unified Process Overview Phases and workflows Terminology Example iteration Reference

More information

COURSE NAME: Database Management. TOPIC: Database Design LECTURE 3. The Database System Life Cycle (DBLC) The database life cycle contains six phases;

COURSE NAME: Database Management. TOPIC: Database Design LECTURE 3. The Database System Life Cycle (DBLC) The database life cycle contains six phases; COURSE NAME: Database Management TOPIC: Database Design LECTURE 3 The Database System Life Cycle (DBLC) The database life cycle contains six phases; 1 Database initial study. Analyze the company situation.

More information

Using UML Part One Structural Modeling Diagrams

Using UML Part One Structural Modeling Diagrams UML Tutorials Using UML Part One Structural Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

Sequence Diagram Sequence Diagrams use case realizations Logical View

Sequence Diagram Sequence Diagrams use case realizations Logical View Sequence Diagrams A Sequence Diagram shows object interactions arranged in time sequence It depicts the objects and classes involved in the scenario, and the sequence of messages exchanged between the

More information

Module 3 The RUP Test Discipline

Module 3 The RUP Test Discipline Module 3 The RUP Test Discipline Principles of Software Testing for Testers Module 3: The RUP Test Discipline Topics Objectives...3-2 What is the Rational Unified Process (RUP)?...3-3 Overview of the Software

More information

Source Code Translation

Source Code Translation Source Code Translation Everyone who writes computer software eventually faces the requirement of converting a large code base from one programming language to another. That requirement is sometimes driven

More information

CSC 402 Software Engineering I. Overview - Design

CSC 402 Software Engineering I. Overview - Design Overview - Design Introduction to Design Architectural Design Modules Structured Design Objects Object-Oriented Design Detailed Design Integration Testing 1 Goals and Objectives Develop a coherent representation

More information

Systems Analysis and Design

Systems Analysis and Design Systems Analysis and Design Slides adapted from Jeffrey A. Hoffer, University of Dayton Joey F. George, Florida State University Joseph S. Valacich, Washington State University Modern Systems Analysis

More information

NIMSAD Evaluation of the Rational Unified Process

NIMSAD Evaluation of the Rational Unified Process NIMSAD Evaluation of the Rational Unified Process Introduction Element 1: The Problem Situation Element 2: The Methodology User (Intended Problem Solver) Element 3, Stage 1: Understanding of the Situation

More information

Rational Rose 2000 Quick Start with Rose Visual Basic

Rational Rose 2000 Quick Start with Rose Visual Basic Rational Rose 2000 Quick Start with Rose Visual Basic Copyright 1993-1999 Rational Software Corporation. All rights reserved. Part Number: 800-0127801-000 Revision 2.1, September 1999, (Software Release

More information

Web Contents for Database Design Book

Web Contents for Database Design Book Web Contents for Database Design Book Link to the Authors Web Site The Perpetual Technologies web site, http://www.perptech.com, contains information about relational database technology, with specialization

More information

Contemporary Issues in Systems Design (H3)

Contemporary Issues in Systems Design (H3) IMIS HIGHER DIPLOMA QUALIFICATIONS Contemporary Issues in Systems Design (H3) Wednesday 3 rd December 2014 10:00hrs 13:00hrs DURATION: 3 HOURS Candidates should answer ALL the questions in Part A and THREE

More information

INTRODUCTION ABOUT L5 LAB There are 36 systems (Compaq Presario) installed in this Lab. Their configurations are as follows:

INTRODUCTION ABOUT L5 LAB There are 36 systems (Compaq Presario) installed in this Lab. Their configurations are as follows: CHALAPATHI INSTITUTE OF ENGINEERING &TECHNOLOGY CHALAPATHI NAGAR LAM,GUNTUR DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING INTRODUCTION ABOUT L5 LAB There are 36 systems (Compaq Presario) installed in

More information

IBM Enterprise COBOL for z/os, Version 4.1

IBM Enterprise COBOL for z/os, Version 4.1 Integrate COBOL and Web-based business processes with a service-oriented architecture IBM Enterprise COBOL for z/os, Version 4.1 Highlights Supports Java interoperability with COBOL programs through object-oriented

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior

UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior UML Activity Diagrams: Versatile Roadmaps for Understanding System Behavior by Ben Lieberman Senior Software Architect Blueprint Technologies The core purpose of software development is to provide solutions

More information

Rational Software White Paper

Rational Software White Paper Developing Large-scale Systems with the Rational Unified Process Maria Ericsson Rational Software White Paper Table of Contents History...1 Systems of Interconnected Systems...1 The Software Development

More information

Patterns in Software Engineering

Patterns in Software Engineering Patterns in Software Engineering Lecturer: Raman Ramsin Lecture 16 AntiPatterns 1 Part 1 AntiPatterns Compiled and presented by Brown et al. in 1998. "An AntiPattern describes a commonly occurring solution

More information

TOGAF usage in outsourcing of software development

TOGAF usage in outsourcing of software development Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky

More information

Interaction Diagrams Practical

Interaction Diagrams Practical Interaction Diagrams Practical EASTERN STATE UNIVERSITY (ESU) BACKGROUND The ESU course registration problem will be used as an example throughout the rest of the course The process of assigning professors

More information

Visible Success Stories

Visible Success Stories University of Massachusetts Medical Center - Success Story Whenever software is completed on time there is cause for celebration. When the project is the first 3-tier application built with business components

More information

Workflows in the Rational Unified Process

Workflows in the Rational Unified Process CS2 Software Engineering note 2 Workflows in the Rational Unified Process As with the first note in the Software Engineering series, this note draws heavily on the description of the RUP in Rational s

More information

An assessment strategy for identifying legacy system evolution requirements in ebusiness context

An assessment strategy for identifying legacy system evolution requirements in ebusiness context JOURNAL OF SOFTWARE MAINTENANCE AND EVOLUTION: RESEARCH AND PRACTICE J. Softw. Maint. Evol.: Res. Pract. 2004; 16:255 276 (DOI: 10.1002/smr.296) Research An assessment strategy for identifying legacy system

More information

Chapter 16. Use Cases

Chapter 16. Use Cases Is adaptable and elements of an interaction that are likely to change should be isolated so that they can be easily modified. Is understandable and should be straightforward, involving no hacks, hidden

More information

Chapter 3 Use Cases. Table of Contents. Chapter Overview. Chapter Overview Learning Objectives Notes on Opening Case

Chapter 3 Use Cases. Table of Contents. Chapter Overview. Chapter Overview Learning Objectives Notes on Opening Case Systems Analysis and Design in a Changing World, sixth edition 3-1 Chapter 3 Use Cases Table of Contents Chapter Overview Learning Objectives Notes on Opening Case Chapter Overview This chapter extends

More information

Modeling Web Applications Using Java And XML Related Technologies

Modeling Web Applications Using Java And XML Related Technologies Modeling Web Applications Using Java And XML Related Technologies Sam Chung Computing & Stware Systems Institute Technology University Washington Tacoma Tacoma, WA 98402. USA chungsa@u.washington.edu Yun-Sik

More information

Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS

Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS Agile Business Suite: a 4GL environment for.net developers DEVELOPMENT, MAINTENANCE AND DEPLOYMENT OF LARGE, COMPLEX BACK-OFFICE APPLICATIONS In order to ease the burden of application lifecycle management,

More information

WHITE PAPER. Peter Drucker. intentsoft.com 2014, Intentional Software Corporation

WHITE PAPER. Peter Drucker. intentsoft.com 2014, Intentional Software Corporation We know now that the source of wealth is something specifically human: knowledge. If we apply knowledge to tasks we already know how to do, we call it productivity. If we apply knowledge to tasks that

More information

2. Basic Relational Data Model

2. Basic Relational Data Model 2. Basic Relational Data Model 2.1 Introduction Basic concepts of information models, their realisation in databases comprising data objects and object relationships, and their management by DBMS s that

More information

UML Types of UML Diagrams Class Diagrams Package Diagrams Object Diagrams

UML Types of UML Diagrams Class Diagrams Package Diagrams Object Diagrams UML UML stands for Unified Modeling Language. This object-oriented system of notation has evolved from the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the Rational Software Corporation. These

More information

UML Activity Diagrams: Detailing User Interface Navigation

UML Activity Diagrams: Detailing User Interface Navigation UML Activity Diagrams: Detailing User Interface Navigation by Ben Lieberman, Ph.D. Senior Software Architect Blueprint Technologies This is the third and final article in my series for The Rational Edge

More information

Aveek Gupta, CISA. IPCC Paper 7A: Information Technology Chapter 2

Aveek Gupta, CISA. IPCC Paper 7A: Information Technology Chapter 2 Aveek Gupta, CISA IPCC Paper 7A: Information Technology Chapter 2 * DBMS/RDBMS 1 Administration 2 3 4 5 6 6 7 Models DML and DDL Data Dictionaries Distributed DataBases Object Oriented DataBases Client

More information

MS Access and Database

MS Access and Database Index Introduction to MS Access and Database Hierarchy used in Access Opening/Creating an Existing Database Creating Tables in Database Defining Relationships Creation of report Creating a Form Difference

More information

Data Models, Schemas, and Instances

Data Models, Schemas, and Instances Chapter (2) Database Systems Concepts and Architecture Objectives Understanding the modern database architectures Learning some of the terminologies and basic concepts Learning about data models Defining

More information

Object-Oriented Analysis (OOA) Object-Oriented Analysis. The Analysis Workflow: Entity Class. The Analysis Workflow

Object-Oriented Analysis (OOA) Object-Oriented Analysis. The Analysis Workflow: Entity Class. The Analysis Workflow Object-Oriented Analysis (OOA) Object-Oriented Analysis Xiaojun Qi OOA is a semiformal analysis technique for the object-oriented paradigm There are over 60 equivalent techniques Today, the Unified Process

More information

Announcements. Lecture 10. Developer quality issues

Announcements. Lecture 10. Developer quality issues 2017 Dr. Jeffrey A. Turkstra 1 Announcements CS 307: Software Engineering Lecture 10: Software Design and Architecture Prof. Jeff Turkstra Discuss your product backlog in person or via email by Today Office

More information

IBM SAP International Competence Center. Automated testing for SAP applications with IBM Rational Functional Tester

IBM SAP International Competence Center. Automated testing for SAP applications with IBM Rational Functional Tester IBM SAP International Competence Center Automated testing for SAP applications with IBM Rational Functional Tester Automated testing for SAP applications with IBM Rational Functional Tester About this

More information

Course 103402 MIS. Foundations of Business Intelligence

Course 103402 MIS. Foundations of Business Intelligence Oman College of Management and Technology Course 103402 MIS Topic 5 Foundations of Business Intelligence CS/MIS Department Organizing Data in a Traditional File Environment File organization concepts Database:

More information

Transitioning from Requirements to Design

Transitioning from Requirements to Design Transitioning from Requirements to Design by Paul Reed President Jackson-Reed, Inc. One of the biggest challenges facing software projects is determining when and how to begin the transition from specifying

More information

Verification of Good Design Style of UML Models

Verification of Good Design Style of UML Models Verification of Good Design Style of UML Models Bogumiła Hnatkowska 1 1 Institute of Applied Informatics, Wrocław University of Technology, Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Poland Bogumila.Hnatkowska@pwr.wroc.pl

More information

Object-Oriented Analysis and Design

Object-Oriented Analysis and Design Object-Oriented Software Engineering with UML Hassan Gomaa Dept of Information & Software Engineering George Mason University Reference: H. Gomaa, Chapter 6 - Designing Concurrent, Distributed, and Real-Time

More information