ソフトウェア工学特論 (13)

1. ソフトウェア工学特論(13) 田中　譲

2. Software Engineering with IntelligentPad

3. IntelligentPad as Middleware • Middleware is an attempt to introduce a middle layer between the layer of operating systems and the layer of application programs. • It aims to hide the difference of underlying platforms including their hardware and operating systems by setting a standard middle layer. • From the application development point of view, it aims to provide standard frameworks for the development of typical application programs, a standard library of application components, and standard infrastructures for developing, distributing, managing, accessing, and using these components and frameworks.

4. Middleware treats each server as an atomic object, and provides its proxy object as a standard component. • A proxy object communicates with its server. • It hides the detail mechanism of the server, and provides only the input and output functions of the server. • Middleware focuses on client application systems and their composition. • It provides a standard linkage mechanism to combine application components. • Some middleware systems provide some of their components with their views on the display screen. • Some others provide every component with its view. • Some allows us to embed visual components into compound documents. • The physical embedding does not necessarily imply functional linkage between the embedded component and its base component.

5. Middleware has increased its importance after the remarkable success of WWW and its browser. • They allow us to plug-in application systems in web pages. • These application systems can be easily downloaded at any client site. • If it is compatible with the client platform, a downloaded system can be executed there. • This capability opens up a new vista toward the distribution of reusable components across platforms. • Furthermore, a plugged-in client application system can communicate with its remote server.

6. The three-tier model • Distributed object technologies such as CORBA support the communication among distributed objects. • The WWW and its browser have introduced the third tier between the tier of servers and the tier of clients. • This model of system architectures is called a three-tier model, while the conventional client-server model is called a two-tier model. • The three-tier model makes clients, servers, and their connections network-transparent. They are liberated from their home locations. This technology trend will liberate any components from their home locations. • The publication of client applications also means the publication of services provided by their servers. • The distribution of components across networks realizes the distribution of documents, tools and services.

7. The three-tier model

8. IntelligentPad has already achieved all the above-mentioned goals of middleware. • Its standard API library hides the difference of platforms. • Its pads work as reusable components. • Their connection is simplified and standardized. • They can be transported across different platforms, and can be published by embedding them in web pages. • Documents, tools, and services are all represented as pads, and therefore can be published through the Internet.

9. Concurrent Engineering in Software Development • In the previous section, we observed that pad flow systems can provide basic frameworks for concurrent engineering systems. • Here we focus on concurrent engineering in software development, especially development of client software systems. • As intended since its birth, IntelligentPad can cover the development of most client software systems, which implies that pad flow systems can deliver not only documents and data of products, but also client software products as pads. • Various versions of products and their components can be delivered to and from workers and systems with different responsibilities and different functions.

10. These workers include requirement analysts, interface designers, system architects, system programmers, system integrators, component debuggers, system debuggers, and system evaluators. • A requirement analyst interviews customers to extract their requirements, and clearly specifies requirements. • An interface designer also interviews customers and designs a satisfactory user interface. • A system architect divides the whole system into component modules so that the connection structure among them may satisfy the design framework he or she uses. A system architect also specifies the interface protocols among these component modules.

11. A system programmer develops those components that are not available from the library of reusable components. • A system integrator combines components to compose a required system. • A component debugger debugs the newly developed components, while a system debugger debugs a composed system. A system evaluator evaluates the performance and the usability of the developed system.

12. The automated processing systems include a system-documentation tool, and a system-analysis tool. • A system-documentation tool draws a connection-structure diagram of a given composite system. • A system-analysis tool examines the statistics of a given composite system, and reports what kinds of components constitute the system, how many copies of each component are used, how many other components on the average are connected to each component, and so on.

13. Concurrent engineering is an attempt to introduce concurrent activities among these workers and processing systems. • The most familiar conventional lifecycle model of software development is the well-known ‘waterfall’ lifecycle model, which consists of a sequence of six stepsthe software-concept step, the requirement-analysis step, the architectural-design step, the detailed-design step, the coding-and-debugging step, and the system-testing step.

15. The waterfall model allows no concurrent activities among different stages, while it may allow the backing up to the previous stage. • The project holds a review at the end of each step to determine whether it is ready to advance to the next phase. • The waterfall model is document-driven, which means that the main work products that are carried from a step to another step are documents. • In the pure waterfall model, the steps are also discontinuous. They do not overlap.

16. The waterfall model performs well for product cycles in which you have a stable product definition and when you are working with well-understood technical methodologies. • In such cases, the waterfall model helps you to find errors in the early, low cost stages of a project. • The waterfall model also helps to minimize planning overhead because you can do all the planning up front. • The disadvantages of waterfall model arise from the difficulty of fully specifying requirements at the beginning of the project. • This contradicts with modern business needs; the goal is often not to achieve what you said you would at the beginning of the project, but to achieve the maximum possible within the time and resources available.

17. When pads are used to develop client software products, different workers and various kinds of automated processing can exchange various versions of intermediate development results as pads. • In IntelligentPad, a client software system is either a composite pad, or a set of composite pads that are mutually connected by wiring pads. • An interface designer first draws a rough sketch of the GUI, which is passed to a system architect. • A system architect designs the composition structure of the system, and specifies the slot list of each component pad. • The result is a composition diagram as shown in the next figure with functional specification of each slot and the data type specification of each slot-access message.

19. More than one system architect can share this information to collaborate. If the overall system can be divided into several subsystems, each system architect may work on individual subsystem. • The architectural design results are passed to a system programmer. • He or she first searches the library of reusable pads for necessary component pads, and develops each unfound pad by himself or by herself. • System programmers sometime develop a dummy pad for some required component. While a dummy pad does not completely provide the required internal mechanism, it partially mimic the required pad.

20. Some dummy pads mimic only the slot connections of the required pads; some others partially simulate the IO operations of the required pads. • More than one programmer can work on different component pads. • Interface designers may use both nonfunctional pads and some functional pads such as buttons, sliders, and display pads to design the GUI. • They can sometime use dummy pads, which provides more reality in the process of interaction design.

21. IntelligentPad further allows an interface designer to modify the developed product. • He or she may change the layout of components, or even replace some of them with its alternative pad of the same function. • A system integrator combines the pads from the library and the newly developed pads, in the same structure as the composition diagram, to compose a system that satisfies the system requirement. • A component debugger debugs each component pad independently from other components. • A system debugger may use dummy pads to test the connection of each component pad with the other components. • A system evaluator may also sometime use dummy pads to evaluate the usability of a component pad or a component composite pad.

22. These processes mentioned above indicate that there are lots of concurrency among themselves. • Similarly there are also lots of concurrency between these workers’ processes and various kinds of automated processing. • The sharing and exchange of such intermediate development results and their documents, both as pads, by using the pad flow system framework enable both these workers and processing tools at distributed remote locations to collaborate in the development of client software systems.

23. Components and Their Integration • The granularity of components ranges from a complex database server to a simple button. • The IntelligentPad architecture can deal with different sizes of components. • It can deal with both coarse-grain components and fine-grain components. • They are all equally treated as pads. • Furthermore, the grain size of a component has nothing to do with its pad size. • A coarser-grain component pad can be pasted on a finer-grain component pad.

24. Componentware inherently brings three new waves. • In the first wave, components are developed and utilized inside the same software production company and its subcontractors. • They are utilized only by application developers to reduce production time and cost. • The reduction of production time and cost will encourage software production companies put more emphasis on customer satisfaction. • Various tastes of users will push software production companies to increase the variety of products that essentially provide the same function, which will lead them to develop customization technologies, and to increase the variety of components for customization. • This change will develop in a very short time, which will make each software production company unable to develop all the necessary components by themselves. Some existing software companies have their specialties.

25. Demands for a large variety of high-quality standard components will grow these specialized companies to become dedicated component developer companies. • They supply components to software production companies. • They will compete with each other on their specialties. • Some may produce good digital video components, while some others may be good at database application components. • Their components are licensed to application development companies, or sold to application users through distributors. • Application users will purchase both application products and application components through distributors. • They customize purchased application products with components they have. • No distribution flow of components is legally allowed among application users.

26. The application development companies will shift their roles from the coding to the integration design. • They design how to decompose their products to standard components and specific ones, ask their subcontractors to develop these specific components, design how to assemble these components to compose the products, and perform their assembly. • Each of them develops some special components by itself to differentiate its products from those of others.

27. In business application market, these application development companies sell not only application products but also component integration services and frameworks. • For example, various database applications share not only components but also their integration structures. • This common denominator including both fundamental components and an integration architecture is called an application framework for database applications. • Application frameworks can be found in many typical applications.

28. In end-user market, components will become consumer products. • They will increase their variety. • The same function will be provided by different components with different tastes. • This variety synergistically enlarges their market. • This phenomenon is commonly observed in consumer product market. • Components as consumer products are required to frequently revise themselves. Durable consumer products do not sell well once they are sold.

29. Components as consumer products should be considered as expendable products. • Because of their repetitive revision, their lifecycles are very short. • This is true even for end-user application systems today such as word processors and drawing tools. • These application systems are frequently revised to maintain customers’ satisfaction. If not, new comers will replace them. • Most of them are not durable for more than a year without any revision. • The purchase price of components will become remarkably lowered to encourage users to keep buying new components. • Some suppliers will even distribute free application products and components to enlarge the market, which will allow users to exchange these products and components.

30. The increased variety of application components will stimulate the creativity of end-users, and encourage them not only to customize purchased products with optional components, but also to recombine them to compose new custom products. • This causes no license problem. • This change will bring us a new possibility of viewing end users as application developers. • Their potentiality is remarkably high to enrich the variety of available application software. • Without the distribution of these custom products among users, however, this potentiality will not be realized.

31. The third wave will arrive when even end-users will become able to distribute and exchange application components among themselves. • This change requires a shift from the purchase of products to the purchase of product usage, i.e., from the pay-per-copy billing to the pay-per-use billing. • While the pay-per-copy system requires copy protection, the pay-per-use system allows users to make copies of products. • Furthermore, in the pay-per-use system, users can recombine products to compose custom products, and redistribute them among themselves. • The redistributed custom products may include components and assembly structures that are both some other developers’ properties.

32. Patterns and Frameworks in IntelligentPad • When experts work on a problem arising in some situation, it is quite unusual for them to try to solve it without using their knowledge on how they themselves or others in the same or related domains have ever solved similar problems in similar situations. • Such knowledge consists of rules, each of which is represented by a triple consisting of • a situation or a context, • a problem arising in this context, and • its solution.

33. The architect Christopher Alexander called such a rule a pattern. • He defines this term as follows: Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

34. Contexts and problems can be described at various different levels of abstraction. • Their description at different levels of abstraction defines different levels of their similarities. • Whichever domains they are working in, experts encounter repeatedly similar situations and similar problems. • Their similarities may range from abstract ones to concrete ones, and from functional ones to structural ones. • The level in which we discuss similarities affects our interpretation of what is and isn’t a pattern.

35. Architectural patterns, design patterns, idioms, and frameworks • Patterns can be also found in various levels of software architecture. • Experts in software engineering know these patterns from their experience and reuse them in developing applications. • The pioneer of patterns in software development are Ward Cunningham and Kent Beck, who came up with five patterns dealing with the design of user interfaces. • The first published work about the use of patterns in software engineering was Erich Gamma’s doctoral thesis in 1991. • Later with Richard Helm, Ralph Johnson, and John Vlissides, he extended his work and published a seminal work Design Patterns – Elements of Reusable Object-Oriented Software, which extensively dealt with patterns at certain abstraction level, i.e., design patterns.

36. A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. • It describes a commonly recurring structure of communicating components that solves a general design problem within a particular context.

37. In 1992, James Coplien published the book Advanced C++ Programming Styles and Idioms. • Some other pioneers of patterns are Douglas Schimidt who focused on industrial communication systems, Peter Coad who presented about two hundred patterns in his book, and Wolfgang Pree who focused on structural principles of design patterns for framework development. • In 1996, Frank Bushmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal published the book Pattern-Oriented Software Architecture -- A System of Patterns to deal with patterns at more different levels of abstraction than those dealt with by Design Patterns. • They group patterns into three categories • architectural patterns, • design patterns, and • idioms.

38. An architectural pattern expresses a fundamental structural organization schema for software systems. • It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationship between them. • Architectural patterns help in structuring a software system into subsystems. • Design patterns support the refinement of subsystemsand components, or of the relationships between them. • Whereas an idiom is a low-level pattern specific to a programming language. • An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language.

39. A framework is a partially complete software system that is intended to be instantiated on its use. • It defines the overall architecture for a family of systems, and provides its basic components and the relationships between them. • These remain unchanged in instantiation. • A framework also defines its parts that can be adapted to the specific application needs.

40. Sample composite pads as architectural patterns • Around 1994, when Fujitsu and Hitach Software Engineering developed the first commercially available versions of IntelligentPad, and their system engineers began to use it internally for the development of various different application systems, these system developers also became aware of the frequent use of similar composition structures of pads in the development of different application systems.

41. One of the most typical example of such frequently used composition structures can be found in business applications using databases. • These applications require form interfaces to databases. • A form interface to a database uses a DBProxyPad as the base pad, and, on top of it, a RecordPad with its connection to the #currentRecord slot of the DBProxyPad. To each attribute slot of the RecordPad is connected a TextPad, an ImagePad, a VideoPad, or some other display pad depending on the type of this attribute value. • This description is an example of architectural patterns, or more precisely an application architectural pattern. • It describes the solution part of a pattern. • In IntelligentPad however, we do not need to textually describe the solution part of this pattern as above. Instead, we can provide a sample composite pad that works as a form interface to a sample database. We can further provide several different proxy pads for several widely used DBMSs.

42. Such a sample composite pad works as a pattern, or more precisely as its solution scheme. • It satisfies the following definition of patterns for software architecture: • A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. • The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the way in which they collaborate.

43. A form interface is a particular recurring design problem that arises in specific design contexts, i.e., business application systems accessing databases. • The composition structure of a sample form interface pad presents a well-proven generic scheme for the solution to this problem. • This composition structure as a solution scheme is specified by describing its constituent component pads, their responsibilities and relationships defined by slot connections, and the way in which they collaborate by exchanging standard messages with various types of parameters.

44. Our Web browser pad enables us to make a catalogue of such sample composite pads, which describes each pattern with textual descriptions of its context and problem, and with an embedded sample composite pad we can play with. • A sample composite pad may be used as a component of another sample composite pad. • Patterns are mutually related. Each pattern in this catalogue is associated to its related patterns by navigation links. • For example, a sample form-interface composite pad in our pattern catalogue should be related to a sample QBE (Query-By-Example) DB interface, and various kinds of sample information-visualization tool pads in this pattern catalogue. • This sample form-interface composite pad may be also related to the form-flow framework described in the framework catalogue for IntelligentPad users. • These are linked by bilateral links.

45. Suppose that a sample form-interface has an ImagePad to display an image-type attribute. • The pattern catalogue may provide this ImagePad with an annotation and several link anchors that jump to a Video Pad, a SaverLoaderPad, and an ImagePad having several anchor pads on it. These are the pads that can replace the original ImagePad in the sample form interface.

46. Pad packages with sample compositions as application frameworks • Applications of a certain typical class often share a large number of primitive pads as commonly used components. • Furthermore, they often share the same set of composition structures to combine these commonly used components. • These commonly used components and composition structures are what we call the framework of such applications. • A sample composite pad and its basic primitive pads constitute an application framework in IntelligentPad systems. • A framework may include optional component pads that can replace some components of the sample composite pad.

47. The framework for a form flow system, for example, provides several example form flow systems as sample composite pads, and a set of component pads including sample forms, sample virtual forms, sample form converters, sample form generators and consumers, meta pads, and all the primitive pads for form flow systems. • It provides these pads together with the textual description on their functions, their slots and composition structures, and how to use each of them. • Our Web browser pad enables us to make a catalogue of frameworks, which includes all these pads and their descriptions. Pads and their descriptions in this catalogue may be associated through navigation links with related frameworks in the same catalogue, and also with related patterns in the pattern catalogue.

48. In IntelligentPad, an application package means a family of primitive and composite pads whose slots are standardized with respect to their names and the types of data that are set and got through the slots. • This allows us to easily combine components without knowing the detail semantics of each slot. • Similar situation can be observed among AV components, which standardized not only the shape of their connection jacks and pin-plugs, but also various signals to go through these connection jacks. • Video functions are connected by three cables, yellow, red, and white cables, which respectively send video signals, and left and right sound signals. • The corresponding connection jacks are labeled with “video”, “left”, and “right”.

49. The same is true for a package of pads in IntelligentPad. • More than one package may share the same convention. They are said to belong to the same package family. • More than one package family may coexist in the same application field. They correspond to different communities with different cultures. • While pads in different package families may not be mutually compatible, the introduction of appropriate converter pads by either of these communities or by the third vender may make them interoperable with each other.

50. The architecture of pads as a pattern • The architecture of pads itself is considered as a design pattern or as an architectural pattern. • Each primitive pad is represented as a simplified version of MVC. • A pad pasted on another pad is linked through the connection between their views. • Each primitive pad provides a list of slots, each of which can be accessed only by either a ‘set’ or a ‘gimme’ message. • Furthermore, each pad accepts ‘update’ messages. These three messages can be issued only through the view connection links among pads. An ‘update’ message goes from a parent pad to its child pad, while the other two goes from a child pad to its parent.