Using UML in Software Requirements Analysis – Experiences from Practical Student Project Work

By Dirk Frosch-Wilke

Currently the Unified Modeling Language (UML) is an industry standard for object-oriented analysis and design of software systems. Accordingly, teaching UML is part of curricula in many universities engaged in the field of software engineering. Yet not much has been reported in the literature on how efficiently such courses enable students to use UML in software development projects. In this paper we present the initial results of our ongoing study into the capabilities of students to use the UML in system design projects after having undergone “traditional” and alternative teaching methods in UML classes. In this paper we investigate students’ motivation to follow a use-case driven approach in requirement analysis. We furthermore explore specific problems students are confronted with when using the UML. These findings were gathered during continuous evaluation of a project, in which students were exposed to the real world of systems design, by making the requirement analysis for a customer relationship system. With our study we attempt to optimize our methods of teaching UML in university courses and offer recommendations to this end on the basis of our findings.

Introducing the UML to students is part of curricula in many universities. The reasons for that are manifold:

• the UML is an OMG (Object Management Group) standard,
• the UML has a wide acceptance in industry,
• there are a lot of CASE (Computer Aided Software Engineering)-tools which support the UML,
• use of the UML is independent of software development processes.
• object-oriented design has become very popular in software development projects

Read More/Download

Exploiting UML Extensibility in the Design of Web Applications

By Ekaterina Gorshkova and Boris Novikov

The application design and development methodologies based on UML are well-known, widely used in practice and proved to be critically important for object-oriented design. However, these methodologies and tools do not provide specific support for modelling issues peculiar to web application. This paper defines an UML extension capable to refine the design of the client part of web application. Several new diagrams are specified with provide for precise definition of the content of web pages and navigation between them.

A design and development of a Web application differ significantly from more traditional stand-alone and client-server ones. It usually has to comply with several kinds of requirements like scalability, security (which are common for client-server and web), and portability of the client software (which is more specific for web applications). They are supposed to provide dynamic generation of the user interface, advanced presentation features, and be easily customizable. These requirements make the design of such an application a challenging task.

Several research efforts addressed hypermedia application design focused on data-intensive web-sites. For data model they use entity-relationship model or its extension, for navigation they provide predefined navigation constructs.

Another recent and the closest to us approach is WebML language, which provides orthogonal models for designing structure, composition and presentation. However, it uses its own restricted notation and fails to express advanced composition and navigational constructs. We avoid this kind of limitations relying on the power of UML.

Modeling of web applications with UML is described. This work covers various aspects of the topic. However, this approach uses only class, i.e. static, diagrams to represent both behavioral and structural things, reducing the clarity. Another point is that the stereotypes chosen for this notation are bound to the certain technologies, complicating the creation of conceptual abstract design.

Read more/Download

UML: A Curse or a blessing for the OO community

By Peter Hrushchka

Most methodologies are short on “method” and long on “ology.” When writing this article about the UML, I remembered this quote from the good old Yourdon days of structured methods. With UML, we now have an approach that is very short on method and long only on notation. This article discusses the advantages, disadvantages, experience, joy, and anger of and with the (still incomplete) method wars between data modelers and function modelers. For a long time, people believed in either data flow diagrams or entity-relationship diagrams, but seldom both. Finally, toward the end of the ’80s, people began talking to each other. Even the method gurus started to agree that using data models and function models and behavior models (or so-called real-time extensions) was a good idea for most projects. I call this approach “integrated structured methods,” and it was (and is) good.

But just when we seemed to reach a consensus on the analysis and design approaches, some of the old  and many new gurus started to preach the gospel of OO methods. The first reaction of the market and the CASE vendors was puzzlement, followed by chaos. It was not clear whom to follow. Dozens of notations, dozens of different explanations of what an object is and isn’t, no stability, no trends visible.

It was only when Grady Booch and Jim Rumbaugh joined forces in late 1994 and announced a “unified method” that the average user saw light at the end of the OO tunnel. This unification effort is why I praise UML. The time is right to define strict semantics for the basic OO concepts and agree on definitions and notations. OO is no longer in its pioneer days. We have tried out basic principles long enough to have a deep understanding. A couple of years ago it was fine to experiment with different notations and different concepts, but now we need to settle on a few of them.

Read More/Download

What’s New in UML 2.0?

By Bran Selic

The early part of the 1990s saw a greatly heightened interest in the object paradigm and related technologies. New object-based programming languages, such as SmallTalk, Eiffel, C++, and Java, were devised and adopted. These were accompanied by a prodigious and confusing glut of object-oriented (OO) software design methods and modeling notations. Thus, in his very thorough overview of OO analysis and design methods (covering more than 800 pages), Graham lists more than 50 “seminal” methods [Graham01]. Given that the object paradigm consists of relatively few fundamental concepts, including encapsulation, inheritance, and polymorphism, there was clearly heavy overlap and conceptual alignment across these methods—much of which was obscured by notational and other differences of no consequence. This caused great confusion and needless market fragmentation, which, in turn, impeded the adoption of the useful new paradigm. Software developers had to make difficult and binding choices between mutually incompatible languages, tools, methods, and vendors.

For this reason, when Rational Software proposed the Unified Modeling Language(UML) initiative, led by Grady Booch, Ivar Jacobson, and Jim Rumbaugh, the reaction was immediate and positive. Rational did not intend to propose anything new, but—through collaboration among top industry thought leaders—consolidated the best features of the various OO approaches into one vendor-independent modeling language and notation. Because of that, UML quickly became the first de facto standard and, following its Object Management Group adoption in 1996, a bona-fide industry standard [OMG03a] [OMG04] [RJB05].

Since then, the majority of modeling tool vendors have adopted and supported UML in their tools. The language has became an essential part of the computer science and engineering curricula in universities throughout the world and in various professional training programs; academic and other researchers use it as a convenient lingua franca.

UML also helped raise general awareness about the value of modeling when dealing with software complexity. Although this highly useful technique is almost as old as software itself (with flowcharts and finite state machines as early examples), most practitioners have generally been slow to accept it as anything more than a minor power assist. It is fair to say that this is still the dominant attitude, which is why so-called “model-driven” methods are encountering great resistance in this community.

Read More/Download

Embedded Systems in UML

By Stephen J Mellor

Executable UML models allow the designer to verify the design before any code is written. A translation phase, using a set of rules, builds a system in a strict and repeatable manner. The engineer has full control over these rules to enable generation of the most appropriate code for a particular architecture. Rather than bit-fiddling with the generated code, a more structured and repeatable process is now used. If there is a problem with the behavior of the application, then the model is changed accordingly, and if there is a problem with the performance of the code, then the rules are adjusted. This separation of the application (using the design tool and verify tool) from the architecture (processing the design rules)
results in a more maintainable and efficient system.

Using UML in Embedded Systems
There are many ways in which the UML can be said to be used. Most people use UML informally. That is, they sketch out a few diagrams on the proverbial beer mat and discuss their abstractions with their peers (sic). From there, coding proceeds directly. Martin Fowler’s book, UML Distilled, takes this point of view.

Others use UML as a blueprint that specifies software structure. There is an intended near one-to-one correspondence between the UML diagrams and the code. A tool can generate code frames from these models, and the developer fills in the rest using the models as a guide. Note that if the developer finds a better solution while coding, the model will no longer reflect the code. Users of this approach must have a detailed understanding of their code structure and the corresponding elements in UML. They’ll find UML in a Nutshell useful in this (though the authors do not explicitly promote this approach.).

Read More/Download

Software Testing and the UML

By Clay E. Williams

The Unified Modeling Language (UML) has emerged as an industrial standard for modeling software systems, and has been presented to the International Organization for Standardization for consideration as an international standard. UML has received a great deal of attention (both positive and negative) from the software design and development communities, and work is ongoing to enhance and expand its capabilities. However, the software testing community has had much less awareness and debate about UML, and has largely been absent as the modeling standard was developed. This is an important issues, because in many software development organizations, the cost of testing can account for more than 40% of the total development cost for a software system. Given these facts, this abstract seeks to explore the possibility of using the UML for software testing.

The UML is a visual modeling language that can be used to "specify, visualize, construct, and document the artifacts of a software system". The language itself is specified using a 4-layer meta-model architecture, which partitions the UML into three logical sub-packages: Foundation, Behavioral Elements, and Model Management. UML provides seven views into a software system. These are the static, use case, state machine, activity, interaction, physical, and model management views.

The Foundation package provides the basic infrastructure for exploring the static structure of systems. This infrastructure includes:

• class diagrams - class structure and associations
• component diagrams- map classes to software units
• deployment diagrams - physical system structure

 Read More/Download

Changes between UML Versions

By Martin Fowler

When this book first appeared on the shelves, the UML was in version 1.0. Much of it appeared to have stabalized and it was in the process of OMG recognition. Since then there have been a number of revisions. In this appendix I describe the significant changes that occur, and how they affect the material in this book. If you have an earlier printing of the book, this summarizes the changes so you can keep up to date. I have made changes to the book to keep up with the UML, so if you have a later printing it describes the situation as it was at that time.

Revisions in the UML

The earliest public release what came to be the UML was version 0.8 of the unified method. It was released for OOPSLA (October) 1995. It was called the “Unified Method” and was the work of Booch and Rumbaugh, as Jacobson did not join Rational until then. In 1996 they released a 0.9 and a 0.91 version that included Jacobson’s work. At this time they changed the name to the UML.

Version 1.0 of the UML was submitted to the OMG Analysis and Design Task force in Janurary 1997. It was then combined with other  submissions and a single proposal for the OMG standard was made in Septemember 1997, this was called version 1.1. This was adopted by the OMG towards the end of 1997. In a fit of darkest obfustication the OMG called this standard version 1.0. So it was both OMG version 1.0 and Rational version 1.1, not to be confused with Rational 1.0. In practice everyone calls that standard version 1.1.

UML 1.1 had a number of minor visible changes from version 1.0. When the OMG adopted UML 1.1 they set up a Revision Task Force (RTF) chaired by Cris Kobryn to tidy up various loose ends with the UML. They interally released version 1.2 in July 1998. This release was internal in that 1.1 remained the official UML standard. You could think of version 1.2 as a beta release. In practice this distinction hardly mattered as the only changes in the standard were editorial: fixing typos, grammatical errors and the like.

A more significant change occurred with version 1.3, most notably affecting Use Cases and Activity Diagrams. The amigos’ user guide and reference manual were published late in 1998 with the 1.3 changes, before the official 1.3 documents were made public, which caused some confusion.

In April 1999 the RTF will submit version 1.3 to the OMG as new official standard of the UML. The OMG Analysis and Design Task Force will then take over the UML again and consider any future moves. Of course this is what I currently know, check my web site for future update information

Read More/Download

Extending UML for Agents

By James Odell, H. Van Dyke Parunak and Bernhard Bauer

Gaining wide acceptance for the use of agents in industry requires both relating it to the nearest antecedent technology (object-oriented software development) and using artifacts to support the development environment throughout the full system lifecycle. We address both of these requirements in this paper by describing some of the most common requirements for modeling agents and agent-based systems—using a set of UML idioms and extensions. This paper illustrates the approach by presenting a three-layer AUML representation for agent interaction protocols and concludes by including other useful agent-based extensions to UML.

The Unified Modeling Language (UML) is gaining wide acceptance for the representation of engineering artifacts in object-oriented software. Our view of agents as the next step beyond objects leads us to explore extensions to UML and idioms within UML to accommodate the distinctive requirements of agents. The result is an Agent UML (AUML). Section 2 provides background information on agent design methods in general, on UML, and on the need for AUML. Section 3 introduces a layered approach to representing agent protocols in AUML. Templates and packages provide a high-level summary (Section 4), sequence diagrams and collaboration diagrams furnish alternative views of the interactions among agents (Section 5), and state diagrams and activity diagrams detail the internal behavior of individual agents in executing protocols (Section 6). Section 7 proposes some other UML extensions that represent several commonly used notions employed by the agent community.

Read More/Download

UML Use Case Diagrams

An important part of the Unified Modeling Language (UML) is the facilities for drawing use case diagrams. Use cases are used during the analysis phase of a project to identify and partition system functionality. They separate the system into actors and use cases.

Actors represent roles that can are played by users of the system. Those users can be humans, other computers, pieces of hardware, or even other software systems. The only criterion is that they must be external to the part of the system being partitioned into use cases. They must supply stimuli to that part of the system, and the must receive outputs from it.

Use cases describe the behavior of the system when one of these actors sends one particular stimulus. This behavior is described textually. It describes the nature of the stimulus that triggers the use case; the inputs from and outputs to other actors, and the behaviors that convert the inputs to the outputs. The text of the use case also usually describes everything that can go wrong during the course of the specified behavior, and what remedial action the system will take.

UML Use case diagrams are powerful tools for analysts to use when partitioning the functionality of a system. Use case relationships and the corresponding diagrams help analysts to structure use cases such that their textual descriptions contain a minimum of redundant information; thus making the whole text document much easier to maintain. But use cases are not design tools. They do not specify the structure of the eventual software, nor do they imply the existence of any classes or objects. They are purely functional descriptions written in a formalism that is completely separate from software design.

Read More/Download

UML Tutorial: Part 1 -- Class Diagrams

By Robert C. Martin

UML stands for Unified Modeling Language. It represents a unification of the concepts and notations presented by the three amigos in their respective books. The goal is for UML to become a common language for creating models of object oriented computer software.

In its current form UML is comprised of two major components: a Meta-model and a notation. In the future, some form of method or process may also be added to; or associated with, UML.

UML is unique in that it has a standard data representation. This representation is called the metamodel. The meta-model is a description of UML in UML. It describes the objects, attributes, and relationships necessary to represent the concepts of UML within a software application.

This provides CASE manufacturers with a standard and unambiguous way to represent UML models. Hopefully it will allow for easy transport of UML models between tools. It may also make it easier to write ancillary tools for browsing, summarizing, and modifying UML models.

A deeper discussion of the metamodel is beyond the scope of this column. Interested readers can learn more about it by downloading the UML documents from the rational web site.

Read More/Download

Practical UML: A Hands-On Introduction for Developers

By Randy Miller

This tutorial provides a quick introduction to the Unified Modeling Language. The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML™, which stands for Unified Modeling Language™. The purpose of this course is to present important highlights of the UML.

At the center of the UML are its nine kinds of modeling diagrams, which we describe here.

• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• Statechart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams

Why is UML important?
Let's look at this question from the point of view of the construction trade. Architects design buildings. Builders use the designs to create buildings. The more complicated the building, the more critical the communication between architect and builder. Blueprints are the standard graphical language that both architects and builders must learn as part of their trade.

Writing software is not unlike constructing a building. The more complicated the underlying system, the more critical the communication among everyone involved in creating and deploying the software. In the past decade, the UML has emerged as the software blueprint language for analysts, designers, and programmers alike. It is now part of the software trade. The UML gives everyone from business analyst to designer to programmer a common vocabulary to talk about software design.

The UML is applicable to object-oriented problem solving. Anyone interested in learning UML must be familiar with the underlying tenet of object-oriented problem solving -- it all begins with the construction of a model. A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes.

Models consist of objects that interact by sending each other messages. Think of an object as "alive." Objects have things they know (attributes) and things they can do (behaviors or operations). The values of an object's attributes determine its state.

Classes are the "blueprints" for objects. A class wraps attributes (data) and behaviors (methods or functions) into a single distinct entity. Objects are instances of classes.

Read More/Download

UML basics Part III: The class diagram

by Donald Bell

In June 2003, I began a series of articles titled "UML Basics," designed as an introduction to the Unified Modeling Language. The first article in this series provided high-level introductions to the most widely used diagrams in the UML; the second article offered an in-depth look at the activity diagram.

In this third article, I will focus on the class diagram. Although almost every UML-knowledgeable person claims to understand this diagram, very few actually know the diagram's proper notation set and consequently do not know how to use the diagram. The discussion that follows should enable you to understand and draw a proper class diagram using the UML v1.4 notation set.

This article assumes you have a rudimentary understanding of object oriented design. For those of you who need a little assistance with OO concepts, you might try the Sun brief tutorial about Object Oriented Programming at http://java.sun.com/docs/books/tutorial/java/concepts/. Reading the sections "What Is a Class?" and "What Is Inheritance?" should give you enough understanding to read this article. In addition, David Taylor's book, Object-oriented Technologies: A Manager's Guide, offers an excellent, high-level explanation of object-oriented design without requiring an in-depth understanding of computer programming.

The purpose of the class diagram is to show the static structure of the system being modeled. The diagram specifically shows the entities in the system -- and I literally mean entities, as in "discrete things," not to be confused with "database entities" -- along with each entity's internal structure and relationships with other entities in the system. Because class diagrams only model the static structure of a system, only types of entities
are shown on a class diagram; specific instances are not shown. For example, a class diagram would show an Employee class, but would not show actual employee instances such as Donald Bell, Mike Perrow, or Jimmy Buffett.

Developers typically think of the class diagram as a diagram specifically meant for them, because they can use it to find out details about the system's coded classes or soon-to-be-coded classes, along with each class's attributes and methods.

Class diagrams are particularly useful for business modeling, too. Business analysts can use class diagrams to model a business's current assets and resources, such as account ledgers, products, or geographic hierarchy.

Read More/Download

UML basics Part II: The activity diagram

By Donald Bell

In June 2003, The Rational Edge introduced a new article series by Donald Bell, IBM Global Services, called UML basics. The purpose of this series is to help readers become familiar with the major diagrams that compose much of the UML. Part I offered a general overview of these diagrams; this month, we continue the series with a close look at the activity diagram, including this diagram's complete UML v1.4 notation set.

The purpose of the activity diagram is to model the procedural flow of actions that are part of a larger activity. In projects in which use cases are present, activity diagrams can model a specific use case at a more detailed level. However, activity diagrams can be used independently of use cases for modeling a business-level function, such as buying a concert ticket or registering for a college class. Activity diagrams can also be used to model system-level functions, such as how a ticket reservation data mart populates a corporate sales system's data warehouse.

Because it models procedural flow, the activity diagram focuses on the action sequence of execution and the conditions that trigger or guard those actions. The activity diagram is also focused only on the activity's internal actions and not on the actions that call the activity in their process flow or that trigger the activity according to some event.

Although UML sequence diagrams can protray the same information as activity diagrams, I personally find activity diagrams best for modeling business-level functions. This is because activity diagrams show all potential sequence flows in an activity, whereas a sequence diagram typically shows only one flow of an activity. In addition, business managers and business process personnel seem to prefer activity diagrams over sequence diagrams -- an activity diagram is less "techie" in appearance, and therefore less intimidating to business people. Besides, business managers are used to seeing flow diagrams, so the "look" of an activity diagram is familiar.

Read More/Download

UML basics: An introduction to the Unified Modeling Language

By Donald Bell

This introduction to the Unified Modeling Language, or UML, provides an overview of the most important diagrams used in the visual modeling of computing programs. The article is ideal for those who have little knowledge of UML concepts, including managers as well as novice practitioners.

1997 to be exact -- the Object Management Group (OMG) released the Unified Modeling Language (UML). One of the purposes of UML was to provide the development community with a stable and common design language that could be used to develop and build computer applications. UML brought forth a unified standard modeling notation that IT professionals had been wanting for years. Using UML, IT professionals could now read and disseminate system structure and design plans -- just as construction workers have been doing for years with blueprints of buildings.

It is now the twenty-first century -- 2003 to be precise -- and UML has gained traction in our profession. On 75 percent of the resumes I see, there is a bullet point claiming knowledge of UML. However, after speaking with a majority of these job candidates, it becomes clear that they do not truly know UML. Typically, they are either using it as a buzz word, or they have had a sliver of exposure to UML. This lack of understanding inspired me to write this quick introduction to UML, focused on the basic diagrams used in visual modeling. When you are finished reading you will not have enough knowledge to put UML on your resume, but you will have a starting point for digging more deeply into the language.

Read More/Download

UML 2.1 Tutorial

By Sparx Systems

UML 2.1 advances the successful UML 2.0 specification, and is quickly becoming the accepted standard for specifying, documenting and visualizing software systems. The Unified Modeling Language (UML) is also used for the modeling of non-software systems, and is extensively implemented in most industry sectors including finance, military and engineering.

UML 2 defines thirteen basic diagram types, divided into two general sets:

Structural Modeling Diagrams

Structure diagrams define the static architecture of a model.  They are used to model the 'things' that make up a model - the classes, objects, interfaces and physical components.  In addition, they are used to model the relationships and dependencies between elements.

Behavioral Modeling Diagrams

Behavior diagrams capture the varieties of interaction and instantaneous states within a model as it 'executes' over time; tracking how the system will act in a real-world environment, and observing the effects of an operation or event, including its results.

Read More/Download

Unified Modeling Language (UML) Tutorial

By David Braun, Jeff Sivils, Alex Shapiro and Jerry Versteegh

The Unified Modeling Language (UML) is a standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.1 The UML is a very important part of developing object oriented software and the software development process. The UML uses mostly graphical notations to express the design of software projects. Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.

Goals of UML

The primary goals in the design of the UML were:

• Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.
• Provide extensibility and specialization mechanisms to extend the core concepts.
• Be independent of particular programming languages and development processes.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the OO tools market.
• Support higher-level development concepts such as collaborations, frameworks, patterns and components.
• Integrate best practices.

Why Use UML?

As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.

Read More/Download

Introduction to the Diagrams of UML 2.0

Understanding the thirteen diagrams of UML 2.x is an important part of understanding OO development.  Although there is   far more to modeling than just the UML the reality is the UML defines the standard modeling artifacts when it comes to object technology. 

1. Activity Diagram
   Depicts high-level business processes, including data flow, or to model the logic of complex logic within a system.  See UML Activity diagram guidelines.
2. Class Diagram
   Shows a collection of static model elements such as classes and types, their contents, and their relationships.  See UML Class diagram guidelines.
3. Communication Diagram
   Shows instances of classes, their interrelationships, and the message flow between them. Communication diagrams typically focus on the structural organization of objects that send and receive messages.  Formerly called a Collaboration Diagram.  See UML Collaboration diagram guidelines.
4. Component Diagram
   Depicts the components that compose an application, system, or enterprise. The components, their interrelationships, interactions, and their public interfaces are depicted.  See UML Component diagram guidelines.
5. Composite Structure Diagram
   Depicts the internal structure of a classifier (such as a class, component, or use case), including the interaction points of the classifier to other parts of the system.   
6. Deployment Diagram
   Shows the execution architecture of systems.  This includes nodes, either hardware or software execution environments, as well as the middleware connecting them.  See UML
   Deployment diagram guidelines.
7. Interaction Overview Diagram
   A variant of an activity diagram which overviews the control flow within a system or business process.   Each node/activity within the diagram can represent another interaction diagram.   
8. Object Diagram
   Depicts objects and their relationships at a point in time, typically a special case of either a class diagram or a communication diagram. 
9. Package Diagram
   Shows how model elements are organized into packages as well as the dependencies between packages.  See Package diagram guidelines.
10. Sequence Diagram
    Models the sequential logic, in effect the time ordering of messages between classifiers.  See UML Sequence diagram guidelines.
11. State Machine Diagram
    Describes the states an object or interaction may be in, as well as the transitions between states. Formerly referred to as a state diagram, state chart diagram, or a state-transition diagram.  See UML State chart diagram guidelines.
12. Timing Diagram
    Depicts the change in state or condition of a classifier instance or role over time.  Typically used to show the change in state of an object over time in response to external events. 
13. Use Case Diagram
    Shows use cases, actors, and their interrelationships.  See UML Use case diagram guidelines.

Read More/Download

UML Process

By Sharam Hekmat

UMLProcess is a defined process for developing software systems using object technology. The
purpose of this document is to define the UMLProcess at a level that is suitable for practitioners who have had no prior exposure to a similar process.

This document is intended to be a concise guide to the processes it covers, rather than giving a detailed description of each process. By focusing on the key concepts (and deferring the practical details to workshops and mentoring sessions), we can maximise the usefulness of the handbook as a learning tool.

If you plan to implement the UMLProcess in your organisation, we recommend that you use a UML modelling tool to formalise your modelling activities. PragSoft provides two very popular tools for this purpose:

UMLStudio allows you to create UML models, generate code from them, and reverse engineering UML models from code. UMLServer allows you to deploy UMLStudio in a collaborative environment.

Read More/Download

Introduction to the Unified Modeling Language

If you’re a complete UML beginner, then consider this as UML 101, a basic introduction to the notational elements of the UML.

What is UML?
The easiest answer to that question is a quote: “The UML is the standard language for specifying, visualizing, constructing, and documenting allthe artifacts of a software system.” The more complex answer requires a short history lesson, because the UML is really a synthesis of several notations by Grady Booch, Jim Rumbaugh, Ivar Jacobson and many others.

Read More/Download

Unified Modeling Language

Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group.

UML includes a set of graphical notation techniques to create visual models of software-intensive systems.

The Unified Modeling Language (UML) is used to specify, visualize, modify, construct and document the artifacts of an object-oriented software intensive system under development. UML offers a standard way to visualize a system's architectural blueprints, including elements such as:

    * actors
    * business processes
    * (logical) components
    * activities
    * programming language statements
    * database schemas, and
    * reusable software components.

UML combines best techniques from data modeling (entity relationship diagrams), business modeling (work flows), object modeling, and component modeling. It can be used with all processes, throughout the software development life cycle, and across different implementation technologies. UML has synthesized the notations of the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE) by fusing them into a single, common and widely usable modeling language. UML aims to be a standard modeling language which can model concurrent and distributed systems. UML is a de facto industry standard, and is evolving under the auspices of the Object Management Group (OMG). OMG initially called for information on object-oriented methodologies that might create a rigorous software modeling language. Many industry leaders have responded in earnest to help create the UML standard.

UML models may be automatically transformed to other representations (e.g. Java) by means of QVT-like transformation languages, supported by the OMG. UML is extensible, offering the following mechanisms for customization: profiles and stereotype. The semantics of extension by profiles have been improved with the UML 2.0 major revision.

Read More/Download

This Unified Modeling Language (UML) Dictionary

This Unified Modeling Language (UML) Dictionary, put together by Kendall Scott, is based on version 1.0 of "UML Semantics", whose primary authors are the "three amigos," Grady Booch, Jim Rumbaugh, and Ivar Jacobson. That document provides a formal description of the meta-model that underlies the UML; this document contains much of the same information in a format that I hope people find enlightening and useful. The UML Dictionary has been designed as a supplement to the Addison-Wesley book UML Distilled, by Martin Fowler with Kendall Scott, which has lots of diagrams that illustrate UML notation, plus friendly but authoritative text written by an acknowledged expert in object-oriented analysis and design.

Over 200 terms appear in this Dictionary. Pick a letter, any letter:

by Kendall Scott
I intend to update and expand the UML Dictionary to comform with version 1.1 of the UML, which the Object Management Group (OMG) declared to be a standard in November of 1997. However, I do have a full-time job, and as of February 11, I will be writing another UML book (with Doug Rosenberg, president of ICONIX; this one will focus on use cases), so it will be a while before the 1.1 Dictionary is in place. In the meantime, happy reading!

Read More/Download

How to Draw UML diagrams

What is 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 renowned computer scientists fused their respective technologies into a single, standardized model. Today, UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.

Types of UML Diagrams
UML defines nine types of diagrams: class (package), object, use case, sequence, collaboration, statechart, activity, component, and deployment.

Class Diagrams
Class diagrams are the backbone of almost every object oriented method, including UML. They describe the static structure of a system.

What is a UML Class Diagram?
Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system.

Read More/Download

Database design with UML and SQL, 3rd edition

By Tom Jewett

This third edition of dbDesign is a general update, both to meet legal requirements for U.S. “Section 508” accessibility and to bring the code into compliance with the latest World Wide Web Consortium standards. In the process, I've tried to make the SQL examples as generic as possible, although you will still have to consult the documentation for your own database system. Graphics no longer require the SVG plugin; large-image and text-only views of each graphic are provided for all readers; the menu is now arranged by topic areas; and the print version (minus left-side navigation) is done automatically by a style sheet.

The second edition was largely motivated by the very helpful comments of Prof. Alvaro Monge, as well as by my own observations in two semesters of using its predecessor in class. Major changes included the clear separation of UML from its implementation in the relational model, the introduction of relational algebra terminology as an aid to understanding SQL, and an increased emphasis on natural-language understanding of the design.

Following are the few topics covered in this UML book

• Basic UML & SQL
• Models
• Classes & schemes
• Rows & tables
• Associations
• Keys
• UML design
• Many-to-many
• Many-to-many 2
• Subkeys
• Repeated attributes
• Multivalued attributes
• Domains
• Enumerated domains
• Subclasses
• Aggregation
• Recursive associations
• Normalization
• SQL technique
• Queries
• DDL & DML
• Join
• Multiple joins
• Join types
• Functions
• Subqueries
• Union & minus
• Views & indexes

Read More/Download