Computer Science

"Extreme Programming is the first popular methodology to view software development as an exercise in coding rather than an exercise in management."

"The new concept of Extreme Programming (XP) is gaining more and more acceptance, partially because it is controversial, but primarily because it is particularly well-suited to help the small software development team succeed... XP is controversial, many software development sacred cows don't make the cut in XP; it forces practitioners to take a fresh look at how software is developed."

"One of the things I've been trying to do is look for simpler or rules underpinning good or bad design. I think one of the most valuable rules is avoid duplication. "Once and only once" is the Extreme Programming phrase."

"One of the central axioms of extreme programming is the disciplined use of regression testing during stepwise software development."

"Extreme Programming is an “agile methodology” that some people advocate for the high-speed, volatile world of Internet and Web development."

"Extreme Programming is the most prominent new, light-weight (or agile) methods, defined to contrast the current heavy-weight and partially overloaded object-oriented methods. It focuses on the core issues of software technology. One of its principles is not to rely on diagrams to document a system."

"Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world."

"Object-oriented programming languages support encapsulation, thereby improving the ability of software to be reused, refined, tested, maintained, and extended. The full benefit of this support can only be realized if encapsulation is maximized during the design process. We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach. We show how such an approach can increase the encapsulation by deferring implementation issues until a later stage."

"is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships."

"OOA - Object-Oriented Analysis - is based upon concepts that we first learned in kindergarten: objects and attributes, wholes and parts, classes and members."

"Is object-oriented technology mature enough upon which to build indus­trial-strength systems? Absolutely. Does this technology scale? Indeed. Is it the sole technology worth considering? No way. Is there some better technology we should be using in the future? Possibly, but I am clueless as to what that might be. It is dangerous to make predictions, especially in a discipline that changes so rapidly, but one thing I can say with confidence is that I have seen the future, and it is object-oriented."

"XP (Extreme Programming) is a system of practices (you can use the m-word if you want to; we'd rather not, thank you) that a community of software developers is evolving to address the problems of quickly delivering quality software, and then evolving it to meet changing business needs."

"The key books about object-oriented graphical modeling languages appeared between 1988 and 1992. Leading figures included Grady Booch [Booch,OOAD]; Peter Coad [Coad, OOA], [Coad, OOD]; Ivar Jacobson (Objectory) [Jacobson, OOSE]; Jim Odell [Odell]; Jim Rumbaugh (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; Sally Shlaer and Steve Mellor [Shlaer and Mellor, data], [Shlaer and Mellor, states] ; and Rebecca Wirfs-Brock (Responsibility Driven Design) [Wirfs-Brock]."

"We present a fully automated approach to verifying safety properties of Executable UML models (xUML). Our tool chain consists of a model transformation program which translates xUML models to the process algebra mCRL2, followed by symbolic model checking using LTSmin. If a safety violation is found, an error trace is visualised as a UML sequence diagram. As a novel feature, our approach allows safety properties to be specified as UML state machines."

"Executable UML (xUML) consists of UML class diagrams, UML state machines and an action language which complies with the UML action semantics. There are several action languages in use; we refer to for a—somewhat limited—overview. The xUML models to be translated are expressed in the Cassandra/xUML dialect, as developed by KnowGravity."

"Executable textual modeling tools support automated code generation. For example, supports a number of high-level languages but is targeted towards text parsing and input validation. recently added built-in support for state machines. The State Machine Compiler (SMC) is targeted towards the specification of event driven systems. Microsoft is also developing a textual specification language, AsmL, based on state machine concepts. Those approaches do not incorporate class diagram abstractions and do not support development of complete applications. Executable UML supports a subset of UML textually but misses key features of UML and does not integrate with programming languages."

"What do you think of using UML to generate implementation code? James: I think it’s a terrible idea. I know that I disagree with many other UML experts, but there is no magic about UML. If you can generate code from a model, then it is programming language. And UML is not a well-designed programming language. The most important reason is that it lacks a well-defined point of view, partly by intent and partly because of the tyranny of the OMG standardization process that tries to provide everything to everybody. It doesn't have a well-defined underlying set of assumptions about memory, storage, concurrency, or almost anything else. How can you program in such a language? The fact is that UML and other modelling language are not meant to be executable. The point of models is that they are imprecise and ambiguous. This drove many theoreticians crazy so they tried to make UML "precise", but models are imprecise for a reason: we leave out things that have a small effect so we can concentrate on the things that have big or global effects. That's how it works in physics models: you model the big effect (such as the gravitation from the sun) and then you treat the smaller effects as perturbation to the basic model (such as the effects of the planets on each other). If you tried to solve the entire set of equations directly in full detail, you couldn't do anything."

"Regarding executability, it is clear that from the hypothetical day when a UML virtual machine would be universally adopted, UML-based process models would have a real benefit. Process modelers supposed to be already familiar with UML diagrams would then simply have to draw their process models using their usual UML tools. They would then be able to test, execute and debug them as everyone does with her usual programming language. offers the potential to define such virtual machine thanks notably to the Activity and Action packages, which come with an operational semantics. Some ambiguities in this operational semantics (given in natural language in the standard), have however to be first fixed. This is one of the purposes of a recent initiative at the OMG, called Executable UML"

"Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem."

"Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change."

"Steve Mellor has long been active in this kind of work and has recently used the term Executable UML [Mellor and Balcer, 2002]. Executable UML is similar to MDA but uses slightly different terms. Similarly, you begin with a that is equivalent to MDA's PIM. However, the next step is to use a Model Compiler to turn that UML model into a deployable system in a single step; hence, there's no need for the PSM. As the term compiler suggests, this step is completely automatic."

"Models and simulation furnish abstractions to manage complexities allowing engineers to visualize the proposed system and to analyze and validate system behavior before constructing it. Unified Modeling Language (UML) and its systems engineering extension, (SysML), provide a rich set of diagrams for systems specification. However, the lack of executable semantics of such notations limits the capability of analyzing and verifying defined specifications. This research has developed an executable system architecting framework based on SysML-CPN transformation, which introduces dynamic model analysis into SysML modeling by mapping SysML notations to (CPN), a graphical language for system design, specification, simulation, and verification. A was also integrated into the CPN model to enhance the model-based simulation. A set of methodologies has been developed to achieve this framework. The aim is to investigate system wide properties of the proposed system, which in turn provides a basis for system reconfiguration."

"#The availability of high-quality Model Compilers and Virtual Execution Environments (VEEs) that provide "out of the box" platforms upon which Executable UML models can execute. These VEEs, which exist today in a somewhat incipient stage, will someday soon reduce low-level system architectures to near-commodity status."

"In my opinion this sounds great in theory, but unfortunately there are several problems to making this work in practice:"

"Ever wish you could draw a few diagrams, press a button, and have a working software system that meets your needs? Sound like magic? Perhaps, but that’s a major part of the Executable UML vision. The basic idea is that you will use a CASE tool to develop detailed UML diagrams and then supplement them by specifications written in a formal language, presumably the OMG’s Object Constraint Language (OCL). The basic idea behind Executable UML is that systems can be modeled at a higher level of abstraction than source code, simulated to support validation of your efforts, and then translated into efficient code. This higher-level of abstraction should help to avoid premature design, enable you to change your system as your requirements evolve, and to delay implementation decisions until the last minute."

":I have no doubt that we will begin to see some interesting tools emerge over the next few years based on the Executable UML vision."

"The use of UML collaboration diagrams for specifying complex real-time architectures has been the focus of some recent work. The central idea is to capture architectural specifications in a formal way. This has a number of important advantages. First, it means that the architectural models can be formally analyzed for consistency and completeness. It also means that the models are executable and allow early and precise assessment of the validity of different architectural approaches... Support for this form of UML-based architectural modeling is now available in a commercial tool from Rational Software (Rose RealTime). This tool allows the construction of executable UML models and has the capability of automatic generation of complete systems from such models."

"In its current form UML is designed to support a wide variety of different modelling techniques and formalisms. This is evident, for example, in the state machine formalism which allows both Moore and Mealy formalism with hierarchical states including concurrent sub-states and both synchronous and asynchronous calling semantics. The result of this is not only that almost any state modelling style can be supported but also that many combinations of elements have no defined execution semantics. It is now widely recognised within the UML community, however, that considerable benefit can be gained by forming subsets of the UML with well defined execution semantics. Such subsets can form an “executable UML” which would enable the simulation, execution, testing and ultimately translation of UML models into target code. As part of this movement, work is progressing under the auspices of the OMG towards the definition of “profiles” that define such subsets and towards the more detailed definition of the contents of “actions” including a more precise definition of the execution semantics of UML models."

"The use of UML techniques in TRADE has implications for the semantics of these techniques when they are used this way. s and statecharts are used in TRADE to represent software architecture at the essential level, where we can assume perfect technology. This means, for example, that actions do not take time and that all objects perform their tasks in parallel. A first version of such an essential-level semantics is presented elsewhere. This semantics differs from the OMG semantics, in which actions take time, there are several threads of control and one message queue per thread which can receive signals exchanged by objects. The OMG semantics is clearly intended for and appropriate to what I call the implementation architecture. This is called the design model in the Unified Software Development Process. The use of C++ as action language in the executable UML models of Rhapsody confirms this, as does the outline of the executable statechart semantics given by Harel & Gery..."

"The entire history of software engineering is that of the rise in levels of abstraction. Executable UML is the next logical, and perhaps inevitable, evolutionary step in the ever-rising level of abstraction at which programmers express software solutions. Rather than elaborate an analysis product into a design product and then write code, application developers of the future will use tools to translate abstract application constructs into executable entities... This shift is made possible by the confluence of four factors:"

"Originally UML was intended to serve as a . But a specification is primarily intended to describe properties of systems that the system developers want to be valid, but to leave open other properties that are not clear already. Today this is partly achieved by having a semantics that is rather vague (and here we mean imprecise as opposed to not detailed). However, this is not an advantage, as the developer cannot fix this kind of impreciseness within UML, but can adapt the individual interpretation only. Furthermore, to get complete (and therefore executable) UML descriptions, often certain details have to be specified, which the developer does not yet know or wants to leave open to a later phase of development or even implementation. It is an intrinsic problem of executable languages that this kind of over-specification frequently occurs. Instead it would be of some help to have flexible concepts of under-specification to postpone detail decisions to situations, where the decisions can and must be made."

"Today some evidence arises that UML will more and more be used not as a but as a high level programming language. This has some advantages, as if the concepts of UML are executable, they can immediately be animated and tested, or the generated code even be used as implementation. Thus UML probably will have an implementation-oriented semantics describing this animation."

"The (UML) is a general-purpose visual 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."

"#The development of the Model Driven Architecture (MDA) standards by the Object Management Group (OMG)"

"I assume that a precisely defined, verifiable, executable, and translatable UML is a Good Thing and leave it to others to make that case... In the summer of 1999, the UML has definitions for the semantics of its components. These definitions address the static structure of UML, but they do not define an execution semantics. They also address (none too precisely) the meaning of each component, but there are "semantic variation points" which allow a component to have several different meanings. Multiple views are defined, but there is no definition of how the views fit together to form a complete model. When alternate views conflict, there is no definition of how to resolve them. There are no defined semantics for actions... To determine what requires formalization, the UML must distinguish clearly between essential, derived, auxiliary, and deployment views. An essential view models precisely and completely some portion of the behavior of a subject matter, while a derived view shows some projection of an essential view... All we need now is to make the market aware that all this is possible, build tools around the standards defined by the core, executable UML, and make it so..."

"#The adoption of the Precise Action Semantics for the Unified Modeling Language specification by the OMG in November of 2001"

"#A proposed profile of UML—Executable UML—supports creating a complete and implementation-neutral self-contained expression of application functionality. Steven J. Mellor and Marc J. Balcer define this profile in their book Executable UML: A Foundation for Model-Driven Architecture"

"Information management is central to human development. No less is it important that man learn to improve his management of materials."

"The role of information management is to mediate between information technology and information institutions to facilitate their effective planning, organization, control, and operation."

"'Information management' is a term that is preferred to 'information retrieval' by System Development Corporation. Information management is defined as the establishment and utilization of effective procedures for controlling the generation, processing, flow, and use of information."

"The work of the information officer [should be] regarded as the natural dynamic extension of that of the librarian."

"What is involved in information management is ordinarily not the "management" of substantial information per se — in the way that a censor or an Orwellian dictator would "manage" it — but the management of the information process from organization to ultimate use."

"Historically, information management has been a fragmented activity shared among the traditionally independent elements of an organization. Many of the critical data-handling activities (payroll, invoices, payments, inventories, etc.) of an organization have been located in the administrative or financial management offices. Automation of these activities has resulted in placing management responsibilities for computers and information systems in the office of an organization's administrator or controller. Since information-related programs also may be administered by other elements in an organization, in many instances a dispersed information management structure has resulted. For example, activities such as information and library services, statistical functions, information programs, and associated activities (policy, reports, management, procurement, and communications) may not be centrally managed. Often, responsibility for managing these activities and services is shared, and in some instances the jurisdictional responsibility may not be clear. As a result of this fragmented approach, information resources sometimes have been poorly managed and inappropriately used. The current rationale for comprehensive management of information-related activities is that these activities contribute to an organization's effectiveness. According to the general IRM concept, the IRM office within an organization should provide a central focus for all those information activities that support and serve the organization. Also, this office should reflect the organization's specific directions and goals and be consistent with good management practices. The objectives and goals of the IRM office should be formulated to provide a cohesive management framework consistent with organization requirements and values. The IRM policies and procedures should provide a foundation for developing the information architecture and relevant programs required by the organization."

"For many companies and people who really ought to know better, information management is a term synonomous with data processing."

"Software architecture is foundational to the development of large, practical software-intensive applications."

"software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components. Such a system may in turn be used as a (composite) element in a larger system design."

"Software architecture is a relatively young discipline. There is as much confusion in it as there is excitement. In the literature one finds far too many perspectives, approaches, methodologies, frameworks, techniques and tricks."

"The software architecture of a system supports the most critical requirements for the system. For example, if a system must be accessible from a wireless device, or if the business rules for a system change on a daily basis, then these requirements drastically affect the software architecture for the system. It is necessary for an organization to characterize software architectures and the level of qualities that their systems support to fully understand the implications of these systems on the overall enterprise architecture."

"The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds."

"Software architecture is becoming an important part of software design, which helps developers to handle the complexity of large systems."