本文发表在 rolia.net 枫下论坛UML Pattern Language

Abstract

UML Pattern Language is a collection of patterns for UML system modeling. Pattern and UML are all existing concepts or tools. The joint venture of UML and Pattern brings about a new world for our software development community.

UML is a way to document aspects of a system statically and dynamically. Pattern is a way to collect long lasting practices in system design. UML Pattern Language is a toolset for software development society to adapt in the system modeling. The merit of UML Pattern Language is that it is easy to use not only for professionals, but also for new comers. And a satisfied result is always guaranteed.

UML Patterns are well formatted and structured. But they are not limited to the scope of engineering process. Social cultures are sometimes a big portion of UML Patterns.

The life cycle of UML Pattern Language is eternal. The content is developing. The standard is yet up to be established.



1. UML


For most of us, UML is not new. As its name states, UML is a Unified Modeling Language. For those who are still not familiar with UML, the name doesn't tell too much except for its usage, i.e., to model something.

By definition, UML is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.

We are probably already familiar with OMT and hence pre assume that UML is just another similar Object Oriented development tool. Comparing UML with OMT, it is not difficult to conclude its characteristics. In fact, as stated by its name, UML is a unified language. UML is the union of all the proceeding Object Oriented languages. It is the collection of the best practices of the software development community. Namely, it not only includes those Object Oriented ones, but also includes those best approaches that have been developed along side the long history of software engineering.

UML goes beyond the Engineering side of purpose. With OMT, for example, we encounter symbols and diagrams, which is almost always the first thought we have when we mention OMT as our powerful tool. Yet UML has more, and emphasizes more. In this sense, UML helps to set the context or environment of an application, for example system requirements, scope of usage, design process control, and management and deployment of end results. It connects the whole process of software development by modeling through developing, planning and managing. It takes care of the interaction in between the system and its user, manager, developer. So we say that UML looks at product inside to construct reality and looks at outside to interpret the reality. It is important, because a perfect construction is only as good as interpretation.

That's why UML support the concept for Viewpoints. The world can be viewed from different point of views. Each has its own observation and be self explainationary. UML organizes them by top level model and allows recursive representation down from the top. We can get sub model of sub model of sub model of..., and the relations among them are certainly integrated by UML.

UML allows Extensions to localize itself to specific environment or domain. Three kinds of Extensions, Tagged Values, for example { tag = 'value'}, Constraints, for example {age>21} and Stereotypes, for example naming a package to be <<framework>>, are grouped into Profiles. Profiles are then included into the documentation part.

As we can easily see, besides what we have mentioned above, UML is also process independent, programming language independent and technique independent. I will not go though them in detail.




2. Pattern

2.1 what is pattern

Definition from Oxford English Dictionary: A pattern is a regular or logical form, a model, design or instruction for making something, or an excellent example.

Definition for the paper: patterns are structured, best problem solving practices for software development in literary form.

To understand the term Pattern, we may think about a Chinese recipe. I copy a recipe of Shrimp Noodles here with:

Shrimp Noodles
INGREDIENTS
1 1/2 tsp salt,
4 1/2 cups (500 g) flour, sifted
5 oz (150 g) shrimp, shelled
4 egg whites

RECIPE
1. Mince the shrimp into a pulp and mix with the egg whites, salt, and flour. Add enough water to knead a smooth, elastic dough. Roll out into a very thin sheet and fold into 3 layers. Cut crosswise into fine noodles.
2. Heat 5 cups (1,250 ml) of water to boiling and cook uncovered until the noodles are done, about 1 1/2 minutes.
3. Serve the noodles in bowls with high stock or hotbed leek sauce, made by boiling leek, lard, oyster sauce together and thickening the sauce by adding dissolved corn flour.

A problem is raised up: how to make a Chinese Shrimp Noodle? Then a solution is proposed by the master, further more, it can be learned by the inexperienced.

A pattern is first a best practices, at least the best that have been. For Chinese noodle making, with a history of thousands of years long, it is not important any way. But for Software Development, which is lack of centuries of experience, the significance of organizing the best practices becomes obvious.

A pattern is second a rule of thumb, a way to provided a quick starting point for solving a problem. In the short, yet exciting history of Software Development, we have found many rules to get things done properly, patterns offer a home for them.

A pattern is third a template. It can be used repeatedly. It doesn't specify solution. But you can adapt it. It captures the critical aspects of a problem by paying attention to only those basis stuffs. However, it doesn't limit your creative thinking. The room to further develop is there. Likewise, in our Noodle example, "Roll out into a very thin sheet and fold into 3 layers.", you have enough flexibility to interpret how "thin" the sheet you would like, and as long as it is "thin", you are okay. Remember, Pattern is written in literary form.

2.2 why pattern

We don't have enough heroes or masters. In the early golden years of computing, our field is dominated by supper talented people who used to write code at their most extreme of creativeness. That worked for their age, when the project is small in size and short in maintenance and revision duration. Now we are dealing with gigabyte bandwidth of networked environment and thousands of people big projects. Cooperation among software engineers requires unified format and better understanding to each other. You don't want to suppose that an organization with some over 50% of new entrees would be able to daily handle complex design with each other. You may need a culture which can be adapted so that a normal educated naive would be able to make things ready by following steps as simple as 1-2-3-done.

Worse, as the world tends to more and more flexible, changes are always unavoidable. You often find yourself have to reset your design in the same day. Management and users like change, and People doing programming hates change. Yet, this is the life we are living. We see two major reasons of change.

First, misunderstanding. When you work on a wrongly constructed model, the best thing you can get is as wrong as the system is interpreted. By the time it is realized, a change has to be taken. To understand the system well, you got to make your view as wide as possible. You need to understand things outside the system, you need to know the scope of the system and the system itself. Here, we face the culture issue, which has not been focused well enough before. For example, in a project of an organization, you have to understand the company culture in order to understand the system. How the organization's position is in its own world, how its operation is affected, how its clients expect and interact with it, and how it is managed are all subjects we must make clear and reflect in our design. There is no engineering way of doing this. Pattern, on the other hand, describes things literally. It captures and defines the world very similar to the way human brain works. Pattern conveys information that can't be shown by any engineering method. You can record a musician's work in symbols, that is engineering. But without knowing the relevant history, background and biography of the musician, for example Chopin, you have no way to replay it. Pattern contains Context and Forces parts, which is used to setup a flexible but structured constrain of environments that make software engineers very easy to adapt to different situations and thus gain better understanding.

Second, revision. We have already experienced Windows 3.X, Windows 95, Windows 98, Windows 2000. Who knows what the next Windows would be. Our industry wants to survive itself. Constant revision generates constant revenue. Our users wants perfect products. Constant change causes the software life cycle be permanently long. Documentation only won't help solve the problem perfectly. Because people who works on the endless project changes, and technique of programming language changes. New features are added constantly. Pattern helps you determine what you have already have, what you are required to do, what changes has happened in the user and environment side. Pattern weaves them together and stays there as the only thing that has no change. The best way to tackle too many changes is no change.
2.2 Two different pattern approaches

There are different Pattern formats in different disciplines. The biggest difference is between Generative and non-generative.

Generative patterns are concerned with the Act. They are meant to embody the ideals and let the user explore as much as the scope and ambition allow. The sky is there, you fly yourself.

Non-generative Pattern is instructive. Solution is well presented rather than suggestive. It is more in the 1-2-3-done sense. Latter, we will see examples of UML Pattern. They are all in Non-generative format.

No matter which Pattern you choose, you need to understand it first. Then you can use/reuse it without having to worry about the documentation being inappropriately formatted.


2.3 Pattern in real life especially in software engineering

Pattern is everywhere, though not formally stated. In today's IT companies, there is often a so called "Resource Database". From there, an inexperienced of the industry is able to search for the best practices by the name or category of problem. For many problems, what you need to do is simply do a search. The solutions are there for you. And if you can't find a proper one, you may probably put the problem and your solution into the data base. Those are all patterns in similar non-generative format. Some are not well structured strictly according the definition of Pattern, some are not well refined, yet the content and the idea are the same. I can't use those patterns as example because they are private properties.

Lets think of a "doctor on call" scenario. The doctor sits there having no idea of what the problem the next call would ask. And the doctor himself is maybe only a new graduate. He has no experience. He takes a computer in front of him. When the call comes in, after "I am Mr. Doctor, how are you doing?", the doctor asks by reading from the screen

"how may I help you?"
"How does that affect you?"
"How long has that been?"
"What do you mean?"
"what specifically do you feel"
.............
"If I understand correctly, do you mean A?"


Because the best practice suggests him ask only, however, as much as safety questions. From the information he got, he can narrow down the scope to A. He does a search for A. He gets
best questions/solutions there, all dos and don'ts. By doing that recursively, he who is as a no experienced doctor, is able to handle a significantly majority of problems by his own. That is what we have already had in our real life an example of non-generative formatted Pattern.

A generative Pattern of the same problem is like this
" when you are asked a difficult question, don't answer it, don't tell him you don't know the answer. Instead, ask him as many safety questions as possible".

The generative pattern is an Act. Simple, easy to follow. Simple, easy to create new.









3. UML Pattern

UML itself brings together the best practices of an increasingly mature software development community, in particular, structured analysis and design. Patterns are collections of best practices. Patterns and UML are both about best practices.

By using UML wisely, we can adapt pattern idea into UML. By specifically collecting the best UML practices, we specify Patterns for UML.

The problem of how to embed pattern concept into UML as well as how to manipulate UML so as to be patterned is really not a problem. Naturally, they are of many common languages. UML and Patterns can talk to each other.

When we organize UML Patterns structurally and cover all three software modeling levels, the package we get is the UML Pattern Language. In each level, there is a set of Patterns dealing with different problems. We have Domain Patterns, Product Patterns and Component Patterns. We seem to have covered everything of software development. We call it a language. The problems chosen as Pattern Language members are generic, FAQ. There is no regulation of how many Patterns is enough for a level, neither a clearly set of standard of what problem issue is qualified to be a member.

The UML pattern is presented in the following format

Name
The name is chosen with much care. For example, " Configured and Released Packages". It must reflect the essence of solution in as few words as possible.

Problem
The problem to be solved.

Context
Defines the environment that the pattern can be applied. It involves language, technical architectures, business domain, infrastructure and factors that make or prevent the pattern work.

Forces
contains elements which makes the problem hard to be solved. And the facets that are conflicting with each other. The forces must be resolved by the following solution and make a new context.

Solution
the core that is very interesting to all problem solvers

Resulting Context
The new context after the solution is being used.

Discussion
A kitchen sink. Why does the problem exist? Why is the solution workable? Motivations and everything.


The format is a sequentially arranged process. You've got a question; You understand the question, its environment and difficulty; You present solution; You resolve the tension.













4. UML Pattern Language in Software modeling

4.1 Software modeling levels

Software modeling is divided into 3 levels in this paper. They are Domain, product, and Component. There is certainly difference among them. The difference is so big that we need to name and use them separately. The difference is also so little that we name and use them recursively.

Put forward simply, a Domain contains many products, a Product is consisted of many components. And it is still right if you think a component is a sub domain which contains sub products and so on.

Generally speaking, a domain is the highest level of Software development, or a point of view that is taken from far away. It could be of an overall enterprise, an interest, a family of product. It brings together a high-level business model with high level technology architecture. Domain contains context, scope, and vocabulary for engineering, modeling, and management. Determine the Domain is the starting point of every successful design. A system is not well understood unless it is put in a specific domain. The every thing that yahoo company would offer, contain, process, its database, cash flow and web site all consist a Yahoo domain. From Yahoo domain, we know what is inside, what is outside, what is relevant.

A Product is the second level of structure of Software Development. It is generally what can be delivered to the user and management. It is the target of planning, management, revision, and quality assurance. A set of products consists a Domain. A Yahoo search engine is a product. So it has life cycle. Since it has life cycle, you can generally separate a Domain from a Product. Windows 3.1 has a life cycle that is pretty short. That's why we have seen Windows 3.1 born, introduced, matured and died (not completely yet). Anyway, Windows is still alive.

A component is the lowest level of Software Development. A deployment of handling www address is a component for Yahoo search engine. We call it a node. Sometimes they are executable deliveries, and sometimes they are supporting documentation.

Both Pattern and UML pay attention to the world the system resides on and the interactions in between them. For each modeling, put the object into the right spot is hence important. No matter how you are going to tackle the object, you have to know what is inside and what is outside. You don't want to put the object in a wrong scope. The 3 levels that the UML Pattern Language helps to set up are aimed to fit the processes a system modeling may need. The UML Pattern Language user can easily start with using the Domain Pattern, and go down to the Component Pattern.

4.2 UML Pattern language as collections of patterns in each level
Domain/Product/Component

There are different levels in system modeling. Different levels have different problem, context and forces. And the perfect problem name raised is a only a brief description. In reality, we deal with problems in different context which has forces. The goal of system modeling is in the end resolve different forces in each level. Forces are generally conflicting with each other. We see forces in a car design. People likes quick response, power, speed. A bigger engine is the solution. People also need fuel economic. A car gazelles 15 liters of gas for only 100 KM is unbearable. A small displacement engine is the idea. A good car designer can't just ask his end user by saying" tell me, as a bottom line, what do you need?". Mediating the conflict resolves the tenses. That is our goal.

In our software development, we generalize common forces exist in each level. Common means they are true for every pattern in that level. Understanding the common forces to each level helps understand how the UML Pattern Language is organized.

Common Forces of Domain Patterns
.A business domain must be a meaningful chunk of business reality to its end users
.A domain model must be capable of being directly ciliated and explained by its stakeholders
.Users know what they do, but may not know what they know
.Too much detail can be blinding
.Users many not understand their environment or the direction they want to pursue
.Domains are complex abstractions to technologists
.A common language can help members of a group define a common vision
.A common language can help members outside a group understand the common vision.

Common Forces of Products Pattern
.Models abstract complexity
.Models are manageable
.Models proxy tangibility
.Information technology isn't tangible, but is operational
.Information technology is tactical and strategic, as well as operational.
.Information technology is an asset, not just an expense
.Information technology is a corporate asset
.Assets have lives
.Assets should be owned and managed, as well as built and supported
.Asset management will vary, depending on the life cycle stage the product is in
.Ownership should be consistent and identifiable throughout the product's life

Common Forces of Component Patterns
.Component pluggability
.Component replace ability
.Component reusability
.Deployment models are practical abstractions that are meant to help management and change
.To sustain substantial conceptual information in the node
.Nodes tends to be less conceptual
.Different team like to have their standards
.Documentation must be useful and meaningful.


The UML Pattern Language is consisted of UML Patterns to different levels. In Paul Evitts's "A UML Pattern Language", he organized 10 UML Patterns for each level. As in consistence with the definition of Pattern, these Patterns are not designed by the author himself from scratch. He did a lot of research of existing modeling patterns. His true effort is to make them uniformed in the UML Pattern Language format. We may understand that by thinking that the UML Pattern Language is a "stolen knowledge".


Following is an example of Domain Pattern that is used in the book "A UML Pattern Language"

<< Domain Model is Essential >>

Problem
How to understand the important element of a domain

Forces
.A domain model must be capable of being directly validate and explained by the end users.
.Users know what they do, but may not know what they know
.Too much detail an be blinding
.Domain information is critical context for design decisions
.Design decisions must be traceable to the domain

Solution
Document the components of the domain with a minimum of implementation detail. Business activities should be documented with essential business use case. these are, in effect, scripts that describe interactions with business or organization in which actors play essential roles. Things and services in the real world are represented as essential business objects.

Resulting Context
The essential activities, things, and services are identified, packaged labeled and agreed upon. They are made available in diagrammatic form that allows for further massaging as the overall domain model is refined,

Discussion
McMenamin and Palm introduced the idea of essential models back in the dying days of structured analysis. In order to reduce the complexity of the information generated when analyzing the need for a new system, an essential model would contain only elements that represented the ideal system, free of any implementation considerations. Recently, the notion of essential models has been revived by writers such as Larry Constantime. His idea of essential use case is championed by Jacobson and others.

<< end >>

Above example comes from Domain Pattern. We will not present all patterns. We take this example to show the idea of how the UML Pattern Language looks like. Also, we find that the Pattern, even though categorized as Non-generative Pattern, is still very generative. For Patterns, unless they are for technical details as how to "Rotate Text", you don't expect them to be very prescriptive.

Let's see how a prescriptive Pattern can be

<<Tree Routing Pattern>>

Problem
How to connect many similar UML relationships to a class in an efficient way.

Context
Modeling complex relationships of the same type in a static diagram.

Forces
.Relationships that are related are fundamentally connected in the UML meta model.
.Simpler, clear layouts create more lucid UML diagrams.
.Fewer lines are easier to distinguish visually.
.Overloaded relationship lines must make sense semantically.

Solution
Roll UML relationships of the same type pointing to a class up into a single line ( that is, establish a single point of contact with the target class). This is called tree routing . It is so named because the relationship lines branch out from the class in a central trunk line. It is especially appreciate for displaying aggregation and generlization relationships.

Result Context
Controlled diagram clutter by means of spac-efficient line routing.

Discussion
With the exception of time-sequenced graphs, a UML diagram's layout generally has little or no semantic value. However, a lot of the communication value inherent in a UML diagram is still due to the layout skill of the modeler. This is particularly true when a large number if relationships must be drawn between the elements of a UML diagram.

Tree outing is the most efficient and cleanest looking relationship line routing strategy that can be used in static diagrams. Not only does tree routing reduce the overall amount if diagram space and line complexity used, but it also provides a tremendous reduction in anchor space on the target class, especially in large inheritance hierarchies and complex aggregates.

Tree routing has some basic requirements that must be met before it can be used, but they are easy to keep in mind:
. The relationships to be connected to a single trunk must be of the same type.
.Generalization and aggregation relationships form trees better than other UML relationship types, such as dependency and realization
.Associations and aggregations must have the same multiplicity on the trunk end.

Example















The example shows a cleaner diagram. The effect is more obvious when the number of associations grows.


4.3 UML Pattern Language and Object Oriented Design

In the package of UML Pattern Language, discussions of Object Oriented Design are not explicitly separately presented, because both UML and Pattern are inherited to be Object Oriented. Object Oriented concept is everywhere in and an essential element of UML Pattern Language. No need to discuss Object Oriented Design in UML Pattern Language is like no need to discuss love in marriage. Yet, we find many Patterns are very specialized for Object Oriented Design

Let's see Opaque Packages Pattern

Problem
How can the modeler ensure that clients will reference elements inside a package appropriately? How is loose-coupling through well-defined interfaces best achieved? And most importantly, how can this information be communicated via UML as well as enforced in practice?

Context
A UML model consisting of services decomposed into packages

Forces
.Dependency reduction promotes loose coupling and increase plug ability.
.Increasing package count increases the number of dependencies.
.Dependencies within packages increase with the number of elements contained.
.Gateways or facades reduce dependency by providing replace multiple dependencies with one.

Solution
Make packages as opaque as possible by reducing the visibility of members of the package to private or protected. Make only essential elements public such as interfaces, facades, bridges, proxies, and so on. When displaying packages icons in diagrams, be sure to consistently display only the public elements inside them. This will uniformly communicate a clear sense of what is directly usable in the package and what is hidden implementation information. If protected or private elements must be shown, use a color/shading scheme for the package elements that shows what is visible and what isn't.


Example (2.)













Above example shows a package containing public and private elements that use a color scheme. The shading shows which classes or classes are not visible externally to the package. Ordering processing is able to depend on the Customer package only through the customer class.






We have seen how a Pattern in the UML Pattern language look like and how patterns are organized into the UML Pattern Language as a complete tool set. When we use these patterns, we need to map to the right situation. For example, forces for a pattern will not perfectly map to the forces in the situation. Using patterns successfully or not depends on setting the problem appropriately.













5. Discussion

5.1 UML Pattern language so far

A language is what we use to speak, to communicate. English is a language. English speaking people talk to each other in the English language. C is a programming language. Programmers use the C programming language to write code so to talk to machine and each other.

When we think the set of UML Patterns as a language, we see the set as a language of design. It supplies much of the rich vocabulary that can be the base of design so to speak correctly. More over, Both Pattern and UML aim at technical and non-technical part of design, at model itself and its outside world, and at the back and forth interactions in between them.

The UML Pattern Language so far is dialect. It is local. You can start by creating your own small pattern language from all pattern available. Or you adapt the UML Pattern language proposed by masters.

5.2 A predicted future of UML pattern language

By the time software engineering society realizes the importance of UML Pattern Language, we will, at least for certain period of time, be overwhelmed by too many version of such language. We have public patterns and private patterns. Some can be reused and some can't. Some are viewed as best practices and necessary to be included into some variations of UML Pattern Language, and some aren't. People will finally get tired of too many selections. So we need a pattern for pattern selection or an industrial standard to make the language. Is it IEEE, ISO or ASCII?

5.3 The next generation

The author of "A UML Pattern Language" predicts that the pattern language will evolve itself forever so to avoid from being terminated by the history. It is true because Pattern is always whatever the best. It is not true that the current UML Pattern Language will be able to last forever. The content will definitely change itself. The pattern will certainly remain. So the author is right if we quote Eliot T.S.

.........to make an end is to make a beginning
the end is where we start from..............更多精彩文章及讨论，请光临枫下论坛 rolia.net