SEPARATING DESIGNS FROM IMPLEMENTATIONS: ROLE-BASED SOFTWARE DEVELOPMENT Haibin Zhu, Senior Member, IEEE Department of Computer Science and Mathematics, Nipissing University, 100 College Dr., North Bay, ON, Canada, P1B 8L7
[email protected] Abstract This paper explores the nature of software and software development, discusses the importance of specialization in software development, and infers that separation of design and implementation is beneficial to software development. It proposes that roles can be taken as a new mechanism to separate design from implementation. It presents an exciting innovative perspective of software development, i.e., role-based software development. Finally, it shows the most difficult and important tasks of role-based software development. Keywords: Nature of software, Software Development, Design, Implementation, Roles, RoleBased Software Development
1. Introduction Specialization is a key factor in the high production rate of the industrial age. In the famous movie “Modern Times” from 1936, Charlie Chaplin’s character, the Little Tramp, specialized on his tightening skills at a step of a production line. Although this movie was sarcastically criticizing the negative results of industrialization, it still illustrated the fact that specialization can improve production rate. Software engineers have struggled for so many years on raising the software production rate. However, hitherto, the software production rate is still around 2-4 lines of codes (LOC) per person hour [15]. This is far from satisfactory for the software industry. It is apparent that a new approach must be created to manage the complexity of designing and developing large-scale software systems. Separation of concerns is one such possible way. Separation of concerns refers to the ability to identify and manipulate software components that are relevant to a particular aspect. Classification is the primary motivation for the organization and decomposition of software into manageable and comprehensible parts. Many aspects may be relevant to different developers
playing different roles or at different steps during the software development lifecycle [20]. The dominant mechanism in object-oriented programming is the class, which encapsulates data structures and relevant operations. This mechanism is the major abstraction tool in object-oriented programming. However, it is too general to separate the different concerns of a group of objects instantiated from the same class. Roles are considered one mechanism to separate the concerns of a class. Roles are also taken as a mechanism in modeling and analyzing software systems in UML [17]. Specialization attracts more and more interests in the software community. Different people have been involved in different subjects and specialized in different sub-fields, such as database, computer graphics, telecommunications, operating systems and WEB services [14]. The introduction of roles into software design has been hypothesized to reduce software complexity and improve comprehensibility; promote traceability; facilitate reuse, non-invasive adaptation, customization, and evolution; and simplify component integration. Roles are commonly applied concepts in many fields, such as sociology, psychology, social psychology, behavioral science, management, and drama. Roles can be used in different aspects such as natural organizations, task distributions, system analysis, system design, and system construction. The author proposes a role-based software development methodology in order to apply roles completely and fundamentally into software development. In this paper, the author argues that the major obstacles of software production rate are the ambiguities between the steps in software engineering. Because of these ambiguities, some people propose and propagate the extreme programming methodology. It is believed that this ambiguity is inevitable. In this paper, the author emphasizes that it is possible to clearly draw a line between design and implementation and then to have some people specialize at design and others at
implementation. With this specialization, the software production rate may be improved. People are almost everything in software development [5]. Therefore, a possible mechanism is roles. This paper is arranged as follows. Section 2 reviews the major aspects of software engineering; Section 3 explores the nature of software; Section 4 demonstrates the importance of separating designs from implementations, Section 5 introduces the E-CARGO model to software development; Section 6 discusses how roles can be used in the separation of designs and implementation, Section 7 concludes the paper and proposes the topics for future research.
2. Programming, Software Design and Software Architecture Software is a set of items or objects that form a “configuration” that includes programs, documents and data. Software is a product that delivers computing potential, produces, manages, acquires, modifies, displays, or transmits information. Software is also a vehicle for delivering a product that supports or directly provides system functionality; controls other programs (e.g., an operating system); effects communications (e.g., networking software); and helps build other software (e.g., software tools) [13]. Engineering is the application of science to the needs of humanity [8]. This is accomplished through knowledge, mathematics, and practical experience applied to the design of useful objects or processes. Based on this definition, software engineering lacks clear and accurate theoretical foundations, because there is no well-accepted software science in the world, even though the term “software science” was first used in the 1970s [7]. Therefore, software engineering emphasizes practices, processes, and application. Software engineering is generally considered as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; i.e., the application of engineering to software [8]. In the past thirty years, software engineering has been the application of engineering concepts, techniques, and methods to the development of software systems. Software engineering is the process of designing and building computer software within an accepted set of standards for some useful purpose. Software engineering is a rapidly changing discipline. Since software engineering has been proposed in the 1970’s, many methodologies have been proposed to improve software engineering: • The major contribution of structural programming (SP) is discarding the “goto” statement and making programs more readable
than those made by assembly languages and machine languages with sequential, conditional and iterative structures. • Object-oriented software engineering (OOSE) acclaimed that it improved structural programming in all aspects, such as in project management and change facilitation [4]. But until now, it is very difficult to find a real convincing statistics and results to assess the acclaims of OOSE. • Component-based software development (CBSD) is trying to improve the productivity of software development by modeling the successful technologies of hardware such as integrated circuits, chips, and boards [21]. However, the “softness” of software makes components and CBSD too hard to be practical. • Extreme programming (XP) and agile development try to facilitate changes in software development. They are considering the special aspects of software engineering: changes and rapid evolutions. They are arguing and practicing, but there is currently no significant evidence suggesting their acclaims are true. • Aspect-oriented programming (AOP) is a new trial to emphasize the separation of concerns of problems. The advocates of AOP have worked hard for almost ten years [9]; they have attracted many followers and a special programming language (AspectJ) has been developed [10]. But it is still difficult to tell if it is a successful direction for developing software. Software architecture is a description of components and the relationships of the components of software. Software architecture is more concerned about design of an application or a software system [1]. Design is an activity that transforms requirements into a solution framework that facilitates future implementation. In the author’s opinion, architecture is a deliverable of the design activity. Software implementation is putting architecture into reality. From architecture to deliverable software product, implementation (normally coding), is needed. However, there is no clear board line between design and implementation hitherto. Based on many software failures [14], it is inferred that this ambiguity makes many designers and programmers confused in many real large software projects.
3. The Nature of Software and Software Development The nature of software has been argued since the emergence of the first generation computers in the 1940s. Software is a kind of information at abstract
levels rather than a physical entity. Software is a kind of coded and instructive information that describes the algebraic process logic of software system architectures and behaviors in computing [19]. One of the natures of software is from its “softness”. This “softness” leads to four difficult aspects for software development: absence of a fundamental theory, ease of change, rapid evolution of technologies and very low manufacturing costs [11]. Because of the “softness”, software developers encounter more problems in software engineering than their colleagues do in other engineering disciplines such as chemical, mechanical, industrial, electrical and electronic engineering. Because of the “softness”, it is difficult to understand, measure, transfer, transplant and reuse. Because of the “softness”, it is much harder to build reusable software components than to build reusable hardware ones. Another nature of software is intelligence. Every part of a software product running on a computer is an expression of a part of people’s intelligence. If there were a way to express the whole intelligence of people, it would be possible to make a computer as intelligent as people. Building software is actually to formalize social phenomenon with computer languages. Software is normally understood by its performance or the running result. It is difficult to understand software by reading its source code. Software is written for hardware not for people. Software is actually running for people. Software is very simple because a teenager could make software. Software is very complex because a team of hundreds of experienced engineers and scientists cannot guarantee their software is bug-free. The author composes a paradox “software development is difficult because it is easy”. When the author had dinner with the father of Fuzzy, Dr. Lotfi A. Zadeh, at the 2005 IEEE International Conference on Integration and Reuse of Intelligence (IRI 2005), he told me that the most difficult research was that related to people and society. Software stands between people and computers. Every one who wants to use a computer must use software. That is why software development is difficult. Software is to hardware as knowledge is to brain. Software is invisible when a computer is running. What people can see is that created by hardware (sound, moving pictures, graphics and others). To make software visible, usable, and touchable is the major tasks of visualization, user interfaces and virtual reality. Software is in fact an extension of people’s intelligent activities. Software stands between computers and people (Fig. 1). Software exists in a concrete form that is composed of two parts: one is the machine-readable part (M) and the other is people-readable part (P), where, M means the insensible part, such as machine-readable code and data. The time performance and space performance of M are
very important. P is the sensible part. It describes how to design, how to install, how to configure and how to use M such as source code, documents, visualization, sounds, and input devices. Usability, understandability and maintainability are more important for P. Every software tool hopes to shorten and fill the gap between M and P, such as assemblers, interpreters, compilers, virtual machines, and software development platforms. Computers (M)
People (P) Software
Fig. 1. Software between computers and people. There are two aspects to developing software: individual intelligence-related activities (analysis, design and implementation) and collective intelligence-related activities (requirement gathering, team work, tasks distribution, and coordination). A software product itself is individual intelligence-related stuff but software development is a collective intelligence-related job or, even further, a group-related job. Refer to the classical equation about programs [20] : Programs = data structures + algorithms. Another equation can be composed as: Software = structures + processes. Where, structures mean the structures of data, machines, teams and documents; process means the way in which these structures are created and related to each other. A well-accepted and successful engineering paradigm in many engineering disciplines is the water-fall model [13, 15], but it encounters failures in software engineering [11]. That is to say, software engineering methodology must consider the nature of software and find special engineering methodologies. Directly applying engineering methodologies that are successfully applied in chemical, mechanical, industrial, electrical and electronic engineering into software development is not fully successful because of the 'softness'. The extremely low production rate makes software developers very frustrated. Many managers believe that they have overpaid software developers, but they cannot find better ones. Many project managers know that the traditional software engineering methodologies are not as good as they acclaimed, but they must follow these paradigms because there are no better ones to follow. The major reasons of the failure of software projects are from people-related factors [6]. Software engineering is now really at “a learning plateau” in software development, how can a big jump occur? Where is the first light of a new software development revolution? Many people are pursuing answers. Most existing software development methodologies, such as SP, OOSE, and AOP, are concentrating on
software products, i.e., the individual intelligence aspect. They disregard the other important aspect: the procedure of software development, i.e., the collective intelligence aspect. Although XP mainly considers the development procedure, it is still difficult to follow because XP is too “soft” to operate. Hitherto, there is no a science for software, it is inherently difficult to find a concrete foundation for software engineering because engineering is an application of a science. It is needed to find an innovative methodology for software development. It is believed that software development should absorb nutrition from science, engineering and even arts [3]. The proposed methodology is to consider both software product (individual intelligence-related) and software development procedures (collective intelligence-related) and give a consistent methodology for the complete lifecycle of a software project. In this paper, the author presents one way to improve software development by the specialization of software developers with the support of role mechanisms.
4. Why Should We Separate Designs from Implementations? From the difference between architecture and civil engineering, architects belong to the former discipline and builders belong to the latter one. Architects consider bridges, buildings, and houses at aesthetic viewpoints. They consider these artifacts more tightly related with people. But civil engineers consider bridges, buildings, and houses from a mechanical viewpoint. They mainly consider how strong they are, and how they are built in a short time within the budget. They mainly consider more about practical aspects. Therefore, architects and civil engineers are separated. The process of building a house or a bridge is clearly separated into two different steps: architectural design and implementation. Compared with the above separation, it is required to separate software architects or designers from software implementers or programmers. Although traditional software engineering divides the software life cycle into several stages such as analysis, design, implementation, testing, and maintenance, there are still many cases that people in a team may or try do everything they can. Some analysts and designers would like to do some coding because they think the programmers are not as experienced as them. Some programmers would like to suggest how to design based on their early experiences and their knowledge learned. The situation is that the real responsibilities and rights of team members are all ambiguous. Continuing the introduction, it is emphasized that specialization is very important in software development.
“To make the architect’s crucial task even conceivable, it is necessary to separate the architecture, the definition of the product as perceivable by the user, from its implementation. Architecture versus implementation defines a clean boundary between parts of the design task [1].” It can be stated the advantages of the separation between design and implementation or coding. (1) It is a basic requirement for the principle of “divide and conquer”. In a software development team, there are many different people who are taking different responsibilities and accomplishing different tasks. It is needed to separate the people mainly working in design and those in implementation. (2) A software product is developed in an engineering style from communication, planning, modeling, construction, and deployment, where construction is mainly concerned with the details of code while modeling should consider more about software architecture [13]. (3) Conventional SE does not accomplish this requirement, nor does object-oriented SE. Conventional SE uses stepwise refinement of procedure structures. OOSE uses stepwise class specialization. In these two ways, there is no clear boundary between design and implementation, or between modeling and constructions. (4) There is an argument that the ambiguous boundary between design and implementation is a benefit of OOSE. However, in reality, this normally leads to the ambiguity between the responsibilities of designers and programmers in a software development team. That is why one highly qualified programmer may be valued 20 times as an inexperienced programmer [5]. (5) Separating design from implementation can help designers care little about details. This will help designers consider more about the software architecture which is essential for a successful software product. (6) Such separation can help programmers concentrate on their implementation tasks. They can use their energy, experience, skills and wisdom to make the implementation more robust, bug-free and efficient. They do not need to care about the software architecture which is not their responsibilities. (7) Such separation can help people specialize their capabilities on special skills. It can help train people in different categories and save training cost and time. That is to say, it is not needed to teach a software architect how to program with a concrete language or a programming tool. It is not
needed to train programmers how to design highlevel software architecture. What is needed is to only train them to specialize in implementation with a special language or a programming tool.
5. Applying the E-CARGO Model into Software Development A role in a working environment is actually a wrapper with a service interface [16] and request interface [12] as shown in Fig. 2(a) [22]. A person’s role can be divided into two parts: the service interface including incoming messages, and the request interface including outgoing messages. In fact, the human icon in Fig. 2(b) and (c) can be replaced by an agent, object, group or system. Incoming messages
The service interface
The request interface
Outgoing messages
(a) Role
(b) Role player (c) Role playing Fig. 2. A role as a wrapper of a person in a working environment. To support role-based collaboration, the E-CARGO model is developed [23]. A collaborative system ∑ can be described as a 9-tuple ∑ ::= , where C is a set of classes, O is a set of objects, A is a set of agents, M is a set of messages, R is a set of roles, E is a set of environments, G is a set of groups, s0 is the initial state of a collaborative system, and H is a set of users. An object is everything in a system that occupies a memory cell or cells. It can be accessed and its data or status can be changed by operations on it. A class is a template for a group of similar objects. It describes the operations on the group of objects and specifies the data structure of these objects. An agent is a special object that represents a user involved in collaboration. It is defined as a ::= < n, ca, s, Nr , Ng >, where, ca is a special class that describes the common properties of users, n is the identification or name of the agent, s is the set of properties of the agent, Nr means a set of identifications of roles the agent is
playing, and Ng means a set of identifications of groups the agent belongs to. A message is defined as m ::= < n, v, l, P, t > where n is the identification of the message, v is null or the receiver of the message expressed by an identification of a role, l is the pattern of a message, specifying the types, sequence and number of parameters, P is a set of objects taken as parameters with the message pattern l, where P ⊂ O, and t is a tag that expresses any, some or all message. A role shows both the rights and responsibilities of human users. Incoming messages are used to express responsibilities and outgoing messages to express rights. It is defined as r ::= where, n is the identification of the role, I ::= < Min, Mout > denotes a set of messages, wherein, Min expresses the incoming messages to the relevant agents, Mout expresses a set of outgoing messages or message templates to roles, i.e., Min, Mout ⊂ M, Na is a set of identifications of agents that are playing this role; and No is a set of identifications of objects including classes, environments, roles, and groups that can be accessed by the agents playing this role. An environment expresses a structure to build a group. It is specified by roles, the objects accessed by the roles and the cardinalities of agents playing roles. A group is a set of agents that are working on an environment, i.e., a set of agents assigned with roles in the relevant environment. In such a system, A and H, E and G are tightly-coupled sets. A human user and his/her agent play a role together. Every group has an environment. An environment confines a group. With this tight coupling, it is emphasized that a role-based collaborative system is composed of both computers and human beings. From the viewpoint of role-based collaboration, software development is considered as role-based collaborative activities. ∑ can be considered as a software development team. With the participation of people H, such as joining in a team ∑, accessing objects of the team, sending messages through roles, forming a group in an environment, ∑ evolves, develops and functions. The results of the team work are a new state of ∑ that is expressed by the values of C, O, A, M, E, G, and H, where, forms the role-based software product.
6. How can design be separated from implementation with roles? Role-Based Software Development (RBSD) methodology is a possible direction for separating design from implementation. RBSD means that roles are taken
as the underlying mechanisms in all the software development activities. The role mechanisms can be described in three aspects. Different with the traditional activities of software engineering according to the time line, the activities of software development are considered as four interleaved activities in time such as team organization, architecture design, object implementation and system integration.
other team members. Adding a new team member only adds one line of communication between the new person and the chief programmer.
6.1 Team organization By a role-based software process, we mean that in software development there should be clear role specifications, flexible role transitions [2], flexible role facilitations, and flexible role negotiations: • Clear role specification: it is easy for human users and modelers to understand their responsibilities and rights. • Flexible role transition: it is flexible and easy for a human user and components to transfer from one role to another. • Flexible role facilitation: it is easy for people, modelers and programmers to specify roles. Because a system is developing, the existing roles might be required to adjust to correspond to the development of the system or new roles may have to be created. • Flexible role negotiation: it is easy to negotiate the specification between a human user and a role facilitator. For example, a programmer may negotiate with the project manager for some special modules to complete. Modelers may negotiate the roles for a component and aspects of a role.
Fig. 4. The communication in a chief programmer team. We can use roles to make organization even more efficient. A role-based team that derives from the chief programmer team is shown in Fig. 5. In this kind of team, a person only contacts or communicates with the roles specified in the team. Adding a new person into the team does not increase the communication between persons. It only adds one communication between the newly added person and the roles s/he is playing.
Person 1
Person 2
Person 2
Person 2
Person 2 Person 2
Fig. 3. The communication in a peer-to-peer team. Based on Brooks’ Law, adding personnel to a late software project makes it even later [5], because adding a new person will add more communication costs among the people in the team (Fig. 3). This is an unpleasant situation. This situation is improved with a chief programmer team [15] (Fig. 4). In this type of team, the major communication is between the chief programmer and
Programming Secretary
Programmer
Person 2
Programming Secretary (Role)
Chief Programmer
Programmer
Backup Programmer
Programmer
Person 1 Chief Programmer (Role)
Person 3
Programmer (Role)
Person 4
Person 5
Person 6
Fig. 5. The communication in a role-based team. With a role-based approach, software development can be separated into three steps: architecture design (Fig. 6), component design and implementation (Fig. 7), and system integration (Fig. 8). In architecture design, role specification and role relationships are the major tasks for designers to describe; in component design and implementation, object design and implementation are the major tasks for programmers; in system integration, objects and roles are combined together to make a whole system executable. In the following figures, a rectangle is used to express a role, a circle an object, a solid line with a solid circle the requests of a role, a circle with a a solid line the services of a role, and a dashed line a role attachment which means the object is able to play the role. For simplicity, it is assumed that that a role must have at least one agent to currently play it. 6.2 Architecture design Designers are mainly concerned on specifying roles and the relationships among roles. In design, roles are created and put into the pool. In the architecture design, role specification and role relationships are the major tasks for designers to
describe; in component design and implementation, object design and implementation are the major tasks for programmers; in system integration, objects and roles are combined together to make a whole system executable. R2
R1
R3
R5
R7
R4
R8
R6
each role has a relevant object to play and the object can provide the space and speed requirement of that role, the system is complete. Evidently, the above three steps can be done by specialists such as designers, programmers, and system integrators with different experiences and trainings. The integration step shows a lot of scaling capabilities based on how many objects play a single role. The efficiencies of different objects provided by different programmers may be different. Based on these differences, managers of the development team have concrete evaluation criteria for programmers. O1
O2
O3
O4
Fig. 6. Roles: Architecture Design. 6.3 Object implementation In RBSD, programmers are mainly concerned with implementing classes and objects that can play roles. The tasks of object implementation are to accomplish the services based on the provided requests with special objects (data structures and algorithms). In this implementation, programmers may work in parallel. Experienced and highly skilled programmers may produce more objects than novice programmers. Suppose there are M objects, N programmers making objects and each programmer completes one object at T time units. The time to complete M objects is MT/N. Therefore, adding more (Δ) programmers will certainly shorten the time to complete the objects MT/(M+ Δ). This potentially breaks the Brooks’ law [5]. O1
O5
O2
O6
O3
O7
O4
O8
O9
Fig. 7. Object: Role Players and Implementation. There are two possibilities for an object that cannot work: one is that the designers did not give enough provided requests (or rights); or the coders did not completely apply the provided requests (rights). The designers should concentrate on specifying roles and the relevant requests and services, they only need to care about the high-level provision and requests relationships, that is, what roles should be in a system, what roles require, and what roles provide. The implementers will mainly work on how to implement the services with the provided requests. 6.4 System integration With roles and objects, a software product can be obtained by integration, i.e., assigning objects with roles, or having objects play roles. This step will build the deliverable software product (Fig. 8). At this step, objects are assigned to match a role or roles to play. If
R2
R1
R3
R5
R7
R4
R8
R6
O5
O6
O7
O8
O9
Fig. 8. Assign Objects with Roles-System Integration. From Fig.6-8, a system is designed when roles are designed and specified. System construction is to design objects that are qualified to play the roles and arrange objects to play roles. With Fig. 6 and 7, software design is to design roles, and the relationships among the roles, and software implementation is to program objects and have the objects play roles. Based on the above discussion, the skills of designers and programmers are totally different. Designers are experts of role specifications, role relationship analysis and role structure design. Programmers are experts with a special language to create objects to be qualified to play roles specified by designers. They have different considerations, , expertise, and knowledge. This specialization really separates designers and programmers. This will lead to the real separation between design and implementation. Other specialists may also be needed, such as, the experts to couple objects and roles. They know the objects and the basic specification of roles. They are match-makers between roles and objects. They are the bridges between design and implementation. Matchmaking is their major task. These specialists are totally new types of team members compared with the team members in a traditional software development team.
7. Conclusions and Future Work By separating design from implementation, members in a software development team can be specialized at different skills and are not required to know and care about others’ affairs. With roles, the author proposes a framework of role-based software development which directly supports the separation designs from implementations and emphasizes the specialization of team members. From the above discussion, it is demonstrated that clear separation between design and implementation is beneficial to software development and that roles can help implement this separation. However, it is admitted that no available role specification tool exists to really support role-based software development. The most difficult and underlying task that needs to be accomplished as early as possible is the specification of roles and the provision of a useful tool to specify roles. The proposed E-CARGO model has demonstrated an abstract mechanism for role specification, providing concrete tools to specify, store, manage, transfer and apply roles in software development are still needed. The future work will be on a role-based software development tool based on the Eclipse platform. This should be a good way to exhibit the usefulness and malleability of the role mechanisms having been developed.
Acknowledgments This research is supported by (National Sciences and Engineering Research Council of Canada) NSERC Funding and IBM Eclipse Innovation Grant Funding. Thanks to Pierre Seguin for his proofreading this article.
References [1] Albin, S.T., The Art of Software Architecture, Wiley, 2003.
[2] Ashforth, B. E. and Mahwah, N. J., Role Transitions in [3] [4] [5] [6]
[7] [8]
Organizational Life: An Identity-based Perspective, Lawrence Erlbaum Associates, Inc., 2001. Bond, G.W., “Software as Arts”, Communications of the ACM, vol. 48, no. 8, 2005, pp. 118-124. Braude, E. J., Software Engineering: An Object-Oriented Perspective, John Wiley & Sons, 2001. Brooks, F.P., Jr., The Mythical Man-Month, AddisonWesley, 1995. Dryer, D.C., Eisbach, C., and Ark, W.S., “At What Cost Pervasive? A Social Computing View of Mobile Computing Systems”, IBM System Journal, vol. 38, no. 4, 1999, pp. 652-676. Halstead, M. H., Elements of Software Science, North Holand, 1977. IEEE, “IEEE Software Engineering Standards Zone”, http://standards.ieee.org/software/, 2005.
[9] Kiczales,
G., Aspect-oriented programming, ACM Computing Surveys (CSUR), vol. 28 , no. 4es, December 1996. [10] Kiczales, G., Hilsdale, E., Hugunin, J., Kersten, M., Palm, J., Griswold, W.G., “An Overview of AspectJ”, Proc. of 15th European Conference on Object-Oriented Programming, Budapest, Hungary, June 18-22, 2001, pp. 327-354. [11] Kruchten, P., “The Nature of Software: What's So Special About Software Engineering?” IBM Developer Works, http://www128.ibm.com/developerworks/rational/library/4700.html, Apr. 2004. [12] Patternson, J. F., “Comparing the Programming Demands of Single-User and Multi-User Application”, The fourth Symposium on User Interface Software and Technology, ACM Press, Nov. 1991, pp. 87-94. [13] Pressman, R.S., Software Engineering: A Practitioner’s Approach (6th ed.), McGraw-Hill, 2005. [14] Pressman, R.S., and Herron, S.R., Software Shock, Dorset House Publishing, 1991. [15] Schach, S.R., Object-Oriented and Classical Software Engineering (6th Ed.), McGraw-Hill, 2005. [16] Steimann, F., “Role = Interface: A merge of concepts”, Journal of Object-Oriented Programming, vol.14, no. 4, 2001, pp. 23-32. [17] Steimann, F., “A Radical Revision of UML’s Role Concepts”, Proc. of UML 2000, pp. 194–209. [18] Tarr, P. Ossher, H., Harrison, W., and Sutton, S.M., Jr., “N Degrees of Separation: Multi-Dimensional Separation of Concerns”, Proc. of International Conference on Software Engineering (ICSE’99), Los Angles, CA, USA, 1999, pp. 107-119. [19] Wang, Y., “On Cognitive Informatics Foundations of Software Engineering”, Proceedings of the 3rd IEEE International Conference on Cognitive Informatics (ICCI'04), IEEE CS Press, Canada, August, pp. 22-31. [20] Wirth, N., Algorithms + Data Structures = Programs, Prentice Hall PTR, 1978. [21] Zhu, H. “Building Reusable Components with ServiceOriented Architectures”, Proceedings of 2005 IEEE International Conference on Information Reuse and Integration (IEEE IRI-2005), Las Vegas, Nevada, USA, August 15-17, 2005, pp. 96-101. [22] Zhu, H. “Role Mechanisms in Collaborative Systems”, International Journal of Production Research, vol. 41, no. 1, Jan. 2006, 181-193. [23] Zhu, H. and Zhou, M.C., “Role-Based Collaboration and its Kernel Mechanisms”, IEEE Trans. on Systems, Man and Cybernetics, Part C, to appear, 2006.
