Software Engineers

"Mind you, what we are discussing isn’t religion, per se, but religious feeling. This isn’t the feeling someone has toward God—it’s atheistic, and not in the complicated way of Spinoza or whomever. The religious feeling of science fiction is a deep sense of awe at the great mysteries of the universe."

"The cosmos had not chosen humanity after all. In the old timeline, humans had created the apex civilization on earth, but that had been a one-time and accidental chance. In our human conceit, we’d taken the accidental for the inevitable."

"In the remote future, when people remember the history of the mid-twentieth century to the present, all of the great events that seemed so momentous in this period will be milled away, leaving little trace, and only two things that we have overlooked will be seen as more and more important: first, humanity took its first step outside the cradle, and second, humanity then took a step backward. The importance of these two events cannot be overestimated."

"Contemporary China is a complex society in transition. The kinds of technological and social changes that took societies in the west centuries to move through have sometimes been experienced by a mere two generations in China. The anxiety of careening out of balance, of being torn by parts moving too fast and too slow, is felt everywhere."

"In technological terms, space voyages and environmental protections seem different in character, with the former being intense, high speed, and adventurous, with connotations of state-of-the-art technology, while the latter is a gentle green public-service activity, one which, though involving technology, doesn’t give the impression of being as difficult as the former. But that is only an impression. The true situation is: If we want to achieve the present targets for environmental protection, the technology needed is more difficult to develop than that for large-scale interplanetary travel."

"As to the future of humanity, I’m essentially an optimist. I believe that with the advancement of technology, mankind has a hopeful future. But this optimistic view is based on reason: on one hand, whether the future will be bright or be dark depends largely on the choices we make today."

"Numbness to the universe is pervasive in society."

"The world of fantasy and myth isn’t really that large. The universe, as depicted in Eastern and Western mythology alike, is hardly ever larger than two astronomical units in radius. The notion of a light-year could never have made it into a myth because such a scale is beyond the capacity of the mythological imagination. The most magnificent deities of the world of magic are dwarfed by the stars of the world of sci-fi, and its most terrible demons pale in comparison to the sci-fi world’s black holes."

"As a child, I witnessed a great deal of violence and persecution as well as social unrest during The Cultural Revolution...This experience has made me understand the complexity of human nature and society—I’ve realized that the future of human civilization is also full of danger and uncertainty. Such understanding is manifested in my science fiction novels…"

"Of all the unexpected things that might interrupt Chinese science fiction’s development, social unrest has to be the most worrying. I once told readers at a conference that science fiction is the product of leisurely and carefree minds. No one agreed, but I was telling the truth. Only when our lives are stable and quiet can we allow the universe’s catastrophes to fascinate and awe us. If we already live in an environment full of danger, then science fiction won’t interest us. In fact, two of the last three bursts of creative progress that Chinese science fiction underwent were cut short by social unrest, which is lethal to the genre."

"Present-day applications are rather different in many respects. Present-day programs are often very large and are being developed by teams that collaborate over periods spanning several years. These teams may be scattered across the globe. The programmers are not the future users of the system they develop and they have no expert knowledge of the application area in question. The problems that are being tackled increasingly concern everyday life: automatic bank tellers, airline reservation, salary administration, electronic commerce, automotive systems, etc. Putting a man on the moon was not conceivable without computers."

"Software engineering concerns methods and techniques to develop large software systems. The engineering metaphor is used to emphasize a systematic approach to develop systems that satisfy organizational requirements and constraints."

"Almost 2000 years ago, the Roman architect Vitruvius recorded what makes a design good: durability (firmitas), utility (utilitas), and charm (venustas). These quality requirements still hold, for buildings as well as software systems. A well-designed system is easy to implement, is understandable and reliable, and allows for smooth evolution. Badly-designed systems may work at first, but they are hard to maintain, difficult to test, and unreliable."

"Innovative e-business projects start with a design of the e-business model. We often encounter the view, in research as well as industry practice, that an e-business model is similar to a business process model, and so can be specified using UML activity diagrams or Petri nets. In this paper, we explain why this is a misunderstanding. The root cause is that a business model is not about process but about value exchanged between actors. Failure to make this separation of concerns leads to poor business decision-making and inadequate business requirements."

"Computer science is still a young field. The first computers were built in the mid 1940s, since when the field has developed tremendously. Applications from the early years of computerization can be characterized as follows: the programs were quite small, certainly when compared to those that are currently being constructed; they were written by one person; they were written and used by experts in the application area concerned. The problems to be solved were mostly of a technical nature, and the emphasis was on expressing known algorithms efficiently in some programming language. Input typically consisted of numerical data, read from such media as punched tape or punched cards. The output, also numeric, was printed on paper. Programs were run off-line. If the program contained errors, the programmer studied an octal or hexadecimal dump of memory. Sometimes, the execution of the program would be followed by binary reading machine registers at the console."

"Enterprise Engineering is based on the belief that an enterprise, as any other complex system can be designed or improved in an orderly fashion thus giving a better overall result than ad hoc organisation and design."

"The is about those methods, models and tools which are needed to build the integrated enterprise. The architecture is generic because it applies to most, potentially all types of enterprise. The coverage of the framework spans Products, Enterprises, Enterprise Integration and Strategic Enterprise Management, with the emphasis being on the middle two. The proposal for the architecture follows the architecture itself improving the quality of the presentation and of the outcome. De nitions of Generic Enterprise Reference Architecture, Enterprise Engineering/ Integration Methodology, Enterprise Modelling Languages, Enterprise Models, and Enterprise Modules are given. It is proposed how the above could be developed on the basis of previously analysed architectures (and other results too), such as the , the GRAI Integrated Methodology, , and TOVIE."

"Enterprise Engineering is the collection of those tools and methods which one can use to design and continually maintain an enterprise."

"Enterprise architecture (EA) promotes the belief that an enterprise, as a complex system, can be designed or improved in an orderly fashion achieving better overall results than ad-hoc organisation and design. EA is a co-operative effort of designers, analysts and managers and uses enterprise models in the process... enterprise models carry meaning. This resulted in requirements for the enterprise engineering process, which—if not met—can limit the viability of the process. The analysis of the same factors resulted in requirements for improved Enterprise Modelling Tools."

"provides a Reference Architecture (known as the CIMOSA cube) from which particular enterprise architectures can be derived. This Reference Architecture and the associated enterprise modelling framework are based on a set of modelling constructs, or generic building blocks, which altogether form the CIMOSA modelling languages."

"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."

"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."

"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."

"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."

"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]."

"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."

"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."

"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."

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

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

":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 term (MDE) is typically used to describe software development approaches in which abstract models of software systems are created and systematically transformed to concrete implementations.... Full realizations of the MDE vision may not be possible in the near to medium-term primarily because of the wicked problems involved. On the other hand, attempting to realize the vision will provide insights that can be used to significantly reduce the gap between evolving software complexity and the technologies used to manage complexity."

"One of the distinct features of XP is the lack of any documentation whatsoever, except for the code itself. This is a contraposition to the modeling techniques like the Unified Modeling Language (UML), which strongly focus on documentation. XP takes an extreme position there, not even documenting the architecture of the system. Often, it is very difficult to extract the overall structure, behavior or interactions with the environment from the code. The code is a rather detailed and fragile representation of the system’s tasks. Even though the code contains all necessary information about the system, this information is often burdened with details and it is tedious to extract the aspects one is interested in. Therefore, it would be useful to have a more compact system representation. The UML does provide a number of notations that are suited for this purpose. However, the tools so far are not capable of supporting UML in such a manner that it can be well-integrated with the approach of Extreme Programming."

"Advances in hardware and network technologies have paved the way for the development of increasingly pervasive software-based that collaborate to provide essential services to society. Software in these systems is often required to (1) operate in distributed and embedded computing environments consisting of diverse devices (personal computers, specialized sensors and actuators), (2) communicate using a variety of interaction paradigms (e.g., SOAP messaging, media streaming), (3) dynamically adapt to changes in operating environments, and (4) behave in a dependable manner. Despite significant advances in programming languages and supporting integrated development environments (IDEs), developing these complex software systems using current code-centric technologies requires herculean effort."

"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."

"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."

"In all engineering disciplines nowadays, software engineering excluded, there exists an established engineering process to develop a system, which is accompanied by a number of suited modeling description techniques. Software engineering, being a rather new field, has not as yet established any clear methodical guidance or a fully standardized modeling notation."

"The growing complexity of software is the motivation behind work on industrializing software development. In particular, current research in the area of (MDE) is primarily concerned with reducing the gap between problem and software implementation domains through the use of technologies that support systematic transformation of problem-level abstractions to software implementations. The complexity of bridging the gap is tackled through the use of models that describe complex systems at multiple levels of abstraction and from a variety of perspectives, and through automated support for transforming and analyzing models. In the MDE vision of software development, models are the primary artifacts of development and developers rely on computer-based technologies to transform models to running systems."

"Bernhard Rumpe is chair of the Institute for Software Systems Engineering at the Braunschweig University of Technology, Germany. His main interests are software development methods and techniques that benefit form both rigorous and practical approaches. This includes the impact of new technologies such as model-engineering based on UML-like notations and domain specific languages and evolutionary, test-based methods, software architecture as well as the methodical and technical implications of their use in industry. He has furthermore contributed to the communities of formal methods and UML. He is author and editor of eight books and Co-Editor-in-Chief of the Springer International Journal on Software and Systems Modeling."

"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."

"Jackson System Development (JSD) and Object-Oriented Design (OOD) have one major - arguably central - principle in common; namely that the key to software quality lies in the structuring of the solution to a problem in such a way as to reflect the structure of the problem itself. There should be a simple and demonstrable correspondence between a (real world) component of the problem and a (software) component of the solution. The two methods also use similar concepts to describe the problem domain (or 'real world'). It is considered to consist of identifiable objects ('entities' in JSD) and operations that are either performed or suffered by these objects ('actions' in JSD}."

"We follow two rules in the matter of optimization:"

"Systems engineering as an approach and methodology grew in response to the increase size and complexity of systems and projects. It "recognizes each system is an integrated whole even though composed of diverse, specialized structures and sub-functions..." (Chestnut, 1965) This engineering approach to the management of complexity by modularization was re-deployed in the software engineering discipline in the 1960s and 1970s with a proliferation of structured methodologies that enabled the the analysis, design and development of information systems by using techniques for modularized description, design and development of system components. Yourdon and DeMarco's Structured Analysis and Design, SSADM, James Martin's Information Engineering, and Jackson's Structured Design and Programming are examples from this era. They all exploited modularization to enable the parallel development of data, process, functionality and performance components of large software systems. The development of object orientation in the 1990s exploited modularization to develop reusable software. The idea was to develop modules that could be mixed and matched like Lego bricks to deliver to a variety of whole system specifications. The modularization and reusability principles have stood the test of time and are at the heart of modern software development."

"One of the difficulties in thinking about software is its huge variety. A function definition in a spreadsheet cell is software. A smartphone app is software. The flight management system for an Airbus A380 is software. A word processor is software. We shouldn't expect a single discipline of software engineering to cover all of these, any more than we expect a single discipline of manufacturing to cover everything from the Airbus A380 to the production of chocolate bars, or a single discipline of social organization to cover everything from the United Nations to a kindergarten. Improvement in software engineering must come bottom-up, from intense specialized attention to particular products."

"After forty years of currency the phrase "software engineering" still denotes no more then a vague and largely unfulfilled aspiration."

"The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work."

"Most post-mortems of these software disaster projects have indicated that their problems would have been avoided or strongly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Frequently, these projects were swept along by a tide of optimistic enthusiasm during their early phases, which caused them to miss some clear signals of high risk issues which proved to be the project's downfall later. Enthusiasm for new software capabilities is a good thing. But it needs to be tempered with a concern for early identification and resolution of a project's high-risk elements, so that people can get these resolved early and then focus their enthusiasm and energy on the positive aspects of their software product."

"Like many fields in their early stages, the software field has had its share of project disasters: the software equivalents of Beauvais Cathedral, the S.S. Titanic, and the "Galloping Gertie" Tacoma Narrows Bridge. The frequency of these disaster projects is a serious concern: a recent survey of 600 firms indicated that 35% of them had at least one "runaway' software project."

"Success in all types of organization depends increasingly on the development of customized software solutions, yet more than half of software projects now in the works will exceed both their schedules and their budgets by more than 50%."

"The Code-and-Fix Model. The basic model used in the earliest days of software development contained two steps:"