الاثنين، 15 ديسمبر 2008

What is the UML?

Outlines:

ü      What is the UML?

ü      The Purpose of Modeling

ü      Software Development, Methods, and Models

ü      Object-Oriented Software Development

ü      Disciplines of System Development

 

 

What is the UML?

1.       Provides standard mechanisms for visualizing, specifying, constructing, and documenting software systems.

2.     UML provides a language for describing system interactions, supported by a cohesive (تلاحم) set of definitions managed by an official group, the Object Management Group (OMG).

3.     Using UML to enhance project success requires skill, talent, and creativity.

 

Who created UML?
UML was created at Rational Software by methodologists Grady Booch, Ivar Jacobson, and Jim Rumbaugh with input from other leading methodologists, many software vendors, as well as end-users. Its aim is to unify the various existing systems into a best-of-breed modeling language.

 

Is UML a standard?
Yes. UML was adopted by the Object Management Group (www.omg.org) as a standard in November, 1997.

 

Do I really need UML? Can't I just describe how my application is designed using regular words?


While it's certainly possible to describe interrelated processes and code architecture in words, many people prefer to use a diagram to visualize the relationship of elements to one another. UML is a standard way to create these diagrams. As a result, it makes it easier for programmers and software architects to communicate.

 

 

 

The Purpose of Modeling

 

Goal:

The model’s designers, through iterative work, ensure that their models achieve the goals and the requirements of the project under construction. But a model is not final; it is typically changed and updated throughout a project to reflect new insights (عمق الفهم) and the experiences of the designers.

 

A model not only represents a system or organization, promotes understanding, and enables simulation, but it is also a basic unit of development. It specifies a part of the function, structure, and the behavior of a system. A model is not directly observable by its designer or its user, but can be expressed in terms of diagrammatic notation, text, or a combination of both.

 

Many models for software engineering are displayed using a graphical language expressed by shapes, symbols, icons, and arrows, and supported by labels. In fact, models are usually described in a visual language, which means that most of the information in the models is expressed by graphical symbols and connections. The old saying that “a picture speaks a thousand words” is also relevant in modeling. Using visual descriptions helps communicate complex relationships; it also makes the practical modeling work easier.

 

NOTE:

Not everything is suitable for a visual description; some information in models is best expressed in ordinary text.

 

In short, usable models are:

Accurate. They must precisely and correctly describe the system they are representing.

Understandable. They must be as simple as possible, but too simple to accurately fulfill their purpose, and must be easy to communicate.

Consistent. Different views must not express things that are in conflict with each other.

Modifiable. They must be easy to change and update.

 

 

Software Development, Methods, and Models

Many software projects fail. They can fail in many ways.

Excessive cost

Late delivery

Absolute (كامل) failure to meet the requirements and needs of customers

 

Notes

Δ Technical advances, such as object-oriented programming, visual programming, and advanced development environments, have helped to increase productivity of coding, but have not solved these problems.

 

Δ One of the main problems with today’s software development is that many projects start programming too soon and concentrate too much effort on writing code. Many managers lack an understanding of the software development process and become anxious (قلق ومتلهف) when their programming team is not producing code.

 

Δ The use of modeling in software development is the difference between mature (ناضج) software engineering and hacking up code for a temporary solution. Systems are becoming much larger, integrating many different hardware and software components and machines, and distributed over complex architectures and platforms.

 

 

Δ Before UML, many approaches, called methods, were developed that attempted to inject (يحقن أويدخل) engineering principles into the craft (مركب أوصنعة) of software engineering. The most worthwhile (يقام لة وزن) engineering techniques are those that can be described both quantitatively (كمى) and qualitatively (نوعى), and used consistently (منتظم او مطابق لى and predictably (متنبأ).

 

Δ The multitude (جموع او الحشد) of different methods, each with its own unique notation and tools, left many developers confused (يشوش) and unable to collaborate (تعاون). The lack of a well-established notation upon which creators of many methods and tools could agree made it more difficult to learn how to use a good method. Furthermore, most of the early object-oriented methods were immature and best suited for small systems with limited functionality. They did not have the capability to scale up to the large systems that are now common. Indirectly, modeling can encourage a designer or software architect to adopt a more disciplined development process. Directly, models serve as a repository of knowledge.

 

 

Note:

UML has helped improve modeling, making software engineering more mature as a discipline. Now, those who want to work as a software architect must know UML. The Java architecture exam, for example, assumes knowledge of UML. Such progress, in a little over 60 months since initial adoption, represents a remarkable achievement. It is worth knowing how UML evolved, to understand the core elements of the language.

 

 

So we can say that the trends (اتجاة) of the software industry still point to the need for creating models of the systems we intend to build.

 

The Method Wars

Δ Antecedents (سالف) of object-oriented (OO) modeling languages first appeared in the mid-1970s, and continued during the 1980s, but it didn’t become popular until the late 1980s with the advent of programming languages such as C++ and Smalltalk.

 

Δ When object-oriented programming became a success, the need for methods to support software development followed. More than 50 methods and modeling languages appeared by 1994, and a growing problem became finding a single language to fulfill the needs of many different people and projects.

 

Some prominent methods from this era and their contributions are listed as follows:

■■ Coad/Yourdon. This method, also known as OOA/OOD, was one of the first methods used for object-oriented analysis and design. It was simple and easy to learn

■■ OMT. The Object Modeling Technique (OMT) was developed at General Electric by James Rumbaugh and is a straightforward process for performing tests based on a requirements specification, including the object model, the dynamic model, and the functional model, which complement each other to give the complete description of the system.

 

■■ OOSE/Objectory. The OOSE and Objectory methods both build on the same basic viewpoint formed by Ivar Jacobson. The OOSE method

(I. Jacobson et al., 1992) was Jacobson’s own vision of an object-oriented method. The Objectory method was used for building a number of systems from telecommunication systems for Ericsson to financial systems for Wall Street companies. Both methods were based on use cases, which are then implemented in all phases of the development.

 

Acceptance of UML

Δ To establish UML, the designers realized that the language had to be made available to everyone.

 

Δ Companies are free to use it with their own methods. Tool vendors (بائعين) are free to create tools for it, and authors are encouraged to write books about it. During 1996, a number of organizations joined to form the UML Partners consortium (جمعية او اتحاد). These companies included the Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Texas Instruments, Unisys, and Rational.

 

Methods and Modeling Languages

A method, also called a methodology, is an explicit way of structuring one’s thinking and actions. It consists of a process, a standard vocabulary, and a set of rules and guidelines. It tells the user what to do, how to do it, when to do it, and why it is done.

 

Methods contain models, and these models are used to describe something and to communicate the results of the use of a method.

 

The main difference between a method and a modeling language is that the modeling language lacks a process or the instructions for what to do, how to do it, when to do it, and why it is done. Though UML standardizes models and has incorporated elements gathered from many different methods, the development approaches that use UML are as diverse as the environments in which it is used.

 

Object-Oriented Software Development

ü      UML comes from an object-oriented background. One answer to the question “What is the UML?” could be the following: “It is an object-oriented modeling language for modern software systems.”

ü      All the elements and diagrams in UML are based on the object-oriented paradigm (نموذج او مثال).

 

Disciplines of System Development

ü       Requirements

ü       Analysis

ü       Design

ü       Implementation

ü       Test

Source :This is My Summary From 

Wiley::UML 2 Toolkit you can Buy It From This Page

0 التعليقات: