Ivar Jacobson Quotes

The (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is intended to support most existing object-oriented development processes.

A is a complete course of events in the system, seen from a user’s perspective.

The control objects model functionality that is not naturally tied to any other object... We do not believe that the best (most stable) systems are built by only using objects that correspond to real-life entities, something that many other object-oriented analysis and design techniques claim... Behavior that we place in control objects will, in other methods, be distributed over several other objects, making it hard to change this behavior.

The analysis model will not be a reflection of what the problem domain looks like... The reason is simply to get a more maintainable structure where changes will be local and thus manageable. We thus do not model reality as it is, as object orientation is often said to do, but we model the reality as we want to see it and to highlight what is important in our application.

People regard their environment in terms of objects. Therefore it is simple to think in the same way when it comes to designing a model.

When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case.