Topics in Tools and Environments for a Distributed Cooperative Work

1
Topics in Tools and Environments for a
Distributed Cooperative Work

• Koichiro OchimizuJapan Advanced Institute of
  Science and TechnologiesSchool of Information
  Science

2
Outline of Talk

• Definitions
• Software Tools, Software Environments

• Role of Tools and Environments in Software
  Engineering

• Software Engineering by / for Internet
• Open Source Software Development
• Web Engineering

3
What is a Software Tool ?

• Software tools are programs that help us
• Write
• Analyze and Measure programs
• Test and Verify software documents
• Change
• Manage

4
Editors, Compilers, Debuggers

• Familiar and Essential in programming activities

CASE tools ( Computer Aided Software Engineering )

• Familiar and Popular in software engineering
  activities of upstream

5
Types of Software Tools

• Editor
• Compiler, Translator, Generator
• Analyzer, Tester
• Product management
• Version control system
• Software Engineering Database
• Library

6
Languages, Process, and Tools
Language
Tools cannot exist alone
Process
Tools
7
UML and CASE tools

• Very popular now and help us make and analyze
• Use-case Diagrams for defining functional
  requirements
• Collaboration Diagrams for finding analysis
  classes
• Class Diagrams for designing the static structure
• Sequence Diagrams for defining objects
  interaction
• State Diagrams for defining the behavior of each
  object
• Deployment Diagrams for allocating objects to
  machines
• Component Diagrams for packaging

8
CASE Tool is basically a Graphic Editor with
retrieve documents
analyst designer
access to FVS
retrieveIF
programmer
FVS IF
detect conflicts
organizeIF
technical writer
detectIF
detect
retrieve
access to PVS
organize documents
organize
FVS
process
analyze
documents in XML
detect load balance
processIF
PVS
Processed
analyze
detectIF
diagrams
explain
process
extract
load
mails
explanation
detect
record
summary
examineIF
recordIF
make
coordinator
analyst designer
structure
makeIF
examine deliberations
deliberation threads
make a diagram
examine
send receive
mailIF
send / receive an e- mail
participants
9
Java, Analysis, Visual Presentation

• Rational Rose

10
Java, Analysis, Class Library

• Faham Cone tree

11
What is a Software Environment ?

• The collection of software tools
• Environment
• Software Environment
• Software Development Environment (SDE)

12
What is an Integrated Environment ?

• Most of the cases, tools of an environment are
  integrated by some mechanisms
• User Interface
• Product
• Software Process

13
User-Interface centered Integration
Tools are directly manipulated from User-Interface
14
Product centered Integration

• Software development by a team Version Control
  System is essential for collaboration and
  coordination

15
Process centered Integration

• In Large-scaled software Development should
  follow a software process
• Process centered integrated environment
• invokes software tools based on some process
  definition, e.g. workflow

16
Outline of Talk

• Definitions
• Software Tools, Software Environments

• Role of Tools and Environments in Software
  Engineering

• Software Engineering by / for Internet
• Open Source Software Development
• Web Engineering

17
Distinguished Features of Software

• Different from other industrial products,
  software has distinguished features which make
  production of software difficult. They are 1
• Complexity
• Conformity
• Changeability
• Invisibility

1 F.P. Brooks Jr.No silver bullet essence and
accidents of software engineering, IEEE Computer,
20(4), (1987), pp.10--19.
18
And Furthermore

• Human being engaged in
• Defining,
• Designing,
• Implementing
• Testing
• activities has unique weakness in
  complexity?conformity, instability, and
  invisibility.
• It is also difficult to control and coordinate a
  group activity of human beings.

19
What is Software Engineering

• Research on Software Engineering try to introduce
  discipline into these activities
• by providing models, languages, methodologies and
  tools.

20
Role of Tools and Environments

• Software Tool and Software Development
  Environment is a means of making those software
  engineering activities efficient.

21
Outline of Talk

• Definitions
• Software Tools, Software Environments

• Role of Tools and Environments in Software
  Engineering

• Software Engineering by / for Internet
• Open Source Software Development
• Web Engineering

22
Change of Initiative
High Reliability High Productivity
Network Age
MSCulture
IBM Culture
UNIX Culture
(NotePC)
(General-purpose machine)
(WS)
Object-Oriented technologies
Software Development Methods Languages and
Environments Technical Project Management
techniques Quality Assurance techniques System
Integration technologies
Open Source Software Development
Web Engineering
23

• In the days of general-purpose machines, research
  on SE started to achieve the goal,
  high-productivity and high-reliability
• Being sophisticated by the UNIX culture
• Many achievements software development
  methodologies languages and environments
  technical project management techniques quality
  assurance techniques and system integration
  technologies

24
Achievements of Software Engineering(1)

• IT technologies are rapidly-advancing. Software
  engineering technologies could not always fulfill
  all the requirement every period of innovation
• Research on Software engineering follows them
  step by step creating new technologies and
  evolving itself.

See Appendix 2
25
Achievements of Software Engineering(2)

• 1968-1980 Formation of Software Lifecycle Concept
• Programming Methodologies
• Design Methodologies
• Requirement Engineering
• Technical Project Management
• Software Engineering Database
• 1980-1990 Appearance of Prototyping Technologies
• Analysis of Dynamic behavior of Specification
• Formal Methods
• CASE tools

26
Achievements of Software Engineering(3)

• 1985-1995 Software Process Model
• Process Programming
• CMM
• Integrated Environment
• Human factor
• 1985-2002
• Object-Oriented Technologies
• Distributed Computing
• Open Source Software Development
• Web Engineering

27
The State of Affairs(1)Expanding Application Area

• Network application are increasing in the area
  of
• E-business
• Information applicant
• Web
• Need new software tools and environments that can
  handle complex of various types of medias in
  addition to traditional tools and environments
• Need another tools in a system LSI domain for
  specifying and verifying the design products
  consisting of hardware, firmware, and software
  requirement

28
The State of Affairs(2) Paradigm Shift for
Software Development

• The dominant competitive factors of software
  products in future are(1) make software
  skillfully to sell them in large
  quantities(2) high quality(high reliability) to
• high value(low cost, de facto standard,
  high value added)(3) make from scratch to choose
  and combine(4) make in a group of enterprises
  and compete with others groups to
  global cooperation and competition

29
The State of Affairs(3)Change of Development
Style

• Software Engineering by Internet
• Open Source Software Development
• Software Engineering for Internet
• Web Engineering

30
Achievements and Issues
Achievements
Easy-to-change of Data Structure (Information
Hiding) Programming-to-difference
(Class Inheritance) Easy-to-evolve
(Interface inheritance)
Topics
Coarse-grained Reuse ( Design Patterns,
Frameworks) Distributed Computing ( Middleware,
Component-ware)
31
Current Topics in Object Oriented Technologies

• Design patterns by GoF
• Application Frameworks
• Software Components
• Distributed Computing and Middleware such as
  RPC, RMI, CORBA

See Appendix 3
32
Relationships
Independent
System Development path
Architectural styles
Frameworks
Design pattern
New Framework development
Domain dependency
Domain models
Kits
Kits Development
Detailed
Domain taxonomy
Applications
Implementation
Abstract(natural languages or diagrams)
Concrete(machine readable)
38W.M.Tepfenhart and J.J. Cusick,A Unified
Object Topology, IEEE Software Jan/Feb.
pp.31-35,1997.
33
Design Patterns

• (1) Experienced object-oriented designers know
  something inexperienced designer don't. What is
  it ? (2) Such technologies as Interface
  inheritance(or sub-typing) and overriding, object
  composition and delegation are more useful for
  promoting reuse. Experienced designers know
  useful recurring patterns which give us common
  design terms.(3) Design Patterns(4) Micro
  architectures (five Creational Patterns, seven
  Structural Patterns, eleven Behavioral
  Patterns)(5) It is difficult to develop useful
  design patterns.

34
Observer
ConcreteSubject notifies its observers whenever
a change occurs that could make its observers
state inconsistent with its own. After being
Informed of a change in the concrete subject,
ConcreteObserver uses this information to
reconcile its state with that of the subject.39
Observers
Observer Update()
Subject Attach(Observer)
Detach(Observer) Notify()

for all o in observers o -gt Update()
Subject
ConcreteSubject subjectState
GetState()
ConcreteObserver ObserverState Update()
observerState subject-gtGetstate()
return sujectstate
39 Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides, Design Patterns,
Addison-Wesley Publishing
35
Software Engineering by/for Internet

• Newly developing area.
• Various types of distributed co-operative work
  over an internet are now being tried.
• Co-operative work over an Internet requires new
  mechanisms that support collaboration among
  geographically distributed people.

36
Role of the Internet and Web in global software
development and distribution

• New models of software development
• Distributed collaborative software development
• Bazaar-like, open-source software development
• Online software development tools and libraries
• Electronic software distribution
• New models of software sales pay/use,
  pay/fuction
• Project management, configuration management, and
  issue tracking
• Remote software testing and maintenance
• Technical support, training, and education
• Communication, information dissemination, and
  marketing

San Murugesan, Leverage Global Software
Development and Distribution Using the Internet
and Web, IT JOURNAL, Vol. 12, No.3 March 1999.
37
Open Source Software development

• Organizational Structure of OSSD
• Patch from contributors
• Feedback from users
• Core member
• Management of source codes and Control
  directions of software evolution

38
Issues on OSSD

• OSSD naturally correspond to software evolution.
• Issues to be solved are enhancement of version
  control system that can deal with distribution
  related problems
• Should cope with different project and product
  management policies on each site

39
Need additional supports for a distributed
cooperative work
Smoothness of communication
Independency of individuals work
Do ones job A cooperative work is to make
something sharing parts of it (Configuration Mana
gement)
Talk to others Central activity is
communication (CSCW)
40
Problems specific to a distributed cooperative
work

• Cooperation Related Issues
• A cooperative work causes different
  understandings of the state of shared artifacts,
  interface definitions, agreements .
  Such recognition-gaps increase instability of
  the state of the work.

41
Problems specific to a distributed cooperative
work

• Distribution Related Issues
• In a distributed work, we come across a problem
  of how we should handle a situation in which we
  can not communicate with others. We need to
  provide a mechanism which can assist development
  works in an environment isolated with others.

42
Our Approach to the Solution
43
Current State of the Art
Coordination
Awareness
Extracting project state
Active Coordinator with Team Model
CVS logs
Detection of something wrong ( load unbalance)
Influence to work Interfaces Providing context
of the work
Conflict analysis
Java programs
notify
Emails in ML
Extracting deliberation threads
detect
Configuration management Communication management
Future version space
Collaboration
Concurrency
44
Deliberation thread in detail
45
Multi-Party Deliberation Structure
46
Copliens Organizational Pattern

• Group closely related activities( that is, those
  that are mutually coupled in their
  implementation, manipulate the same artifacts, or
  are semantically related to the same domain).
  Name the abstractions resulting from the grouped
  activities, making them into roles. The
  associated activities become the
  responsibilities( job description) of the roles .

J.Coplien, A Development Process Generative
Pattern Language, Pattern Languages of Program
Design 1999.
47
Design of Communication Link

• Proper communication structures between roles are
  key to organizational success. Communication
  follows semantic coupling between
  responsibilities. Physically collocate people
  whom you wish to have close communication
  coupling.

J.Coplien, A Development Process Generative
Pattern Language, Pattern Languages of Program
Design 1999.
48
Team Model (Ochimizu)
Role object Communication path object Distributed
Work Space object Shared artifact object Private
artifact object
49
Web Crisis and Web Engineering

• Development and Maintenance of Web
• Large-scaled complex Structure liked by hyperlink
• Worldwide decentralized concurrent development
  and modification activities
• Short time development and change with high
  frequency
• User-centered development and skills are not
  uniform
• Ad hoc and unreliable
• Efforts to give a solution for the problem is
  called Web Engineering

San Murugesan, Leverage Global Software
Development and Distribution Using the Internet
and Web, IT JOURNAL, Vol. 12, No.3 March 1999.
50
Research on-going

• WebSoft project( UC Irvine )
• Distributed workflow system
• Shared workspace with the following fuctions
• Authentication
• access control
• Versioning
• Locking
• Columbia
• Virtual work space

Roy T. Fielding, E.James. Whitehead, Jr.,
Kenneth. M. Anderson, Gregory A. Bolcer, Peyman
Oreizy, Richard N. Taylor, Web-Based Development
of Complex Information Products, Comm. Of the
ACM, Vol.41, No.8, 1998.
51
Software Engineering v.s. Web Engineering

• The method for constructing complex structure by
  a team was developed in the research area on
  Software Process Modeling
• Basic concept behind software process modeling
  is
• Divide a whole work into smaller units(task)
• Connect them( workflow and communication )
• Providing an information sharing
  mechanism(Information Repository, database,Web)

52
In Web Engineering

• The definition of process may be a quite other
  one
• Decentralize Sub Processes with interaction

?
It is your role
53
Framework of study on Software Engineering

• Studies on Software Engineering should be
  performed with spiral interaction between
  requirements from a real world and basic
  theoretical considerations in academies. The
  framework shown in next page is one of effective
  ways of doing it.

54
Framework

• (1) Declare one's research interest definitely
  and briefly by observing the superficial
  problematic situations in a real world(2) Set
  up a hypothesis on a Solution and its Effect by
  abstracting an Essential Problem(3) Give a name
  both for an abstraction of problem and an effect
  of solution(4) Change your concerns to basic
  theoretical considerations apart from a real
  world. Concentrate your attentions on
  constructing a solution by using proper tools
  such as algebraic expressions, algorithms,
  languages, software tools and so on.(5)
  Evaluate effects of research results by
  performing a field test in a real world to find
  new requirements for technology
  evolution/revolution

55
Assignments

• There are three integration principles to build
  an integrated environment. Describe the each
  fuctionality.
• Software has four distinguished features
  different from other industrial products.
  Describe them by examining the paper written by
  F. Brooks, Jr..
• Software Engineering by/for Internet is one of
  the challenging topics in our research area.
  Summarize the research issues to be studied by
  examining the papers written by S. Murgesan.

56
(No Transcript)
57
Appendix 1My Research Interests
58
My Research Interests

• Developing a Software Development Environment
  for distributed cooperative works over a computer
  network
• Supporting learning on-demand of industry
  people. The goal is to construct a system that
  enable them to acquire knowledge on demand in
  their daily work
• Applying Object-Oriented Technologies to Real
  World

59
Software Process Model and Support Environment
for a Distributed Cooperative Work over a
Computer Network

• Merging communication processes support into
  object-centered activities
• Clear definition of individual responsibility
  and work interfaces
• Decision management made through conversations
• Awareness of recognition gaps and Coordination
  Support
• Acting under existence of inconsistencies and
  ambiguities, sharing instability of the work

60
Need additional supports for a distributed
cooperative work
Smoothness of communication
Independency of individuals work
Do ones job A cooperative work is to make
something sharing parts of it (Configuration Mana
gement)
Talk to others Central activity is
communication (CSCW)
61
Problems specific to a distributed cooperative
work

• Cooperation Related Issues
• A cooperative work causes different
  understandings of the state of shared artifacts,
  interface definitions, agreements .
  Such recognition-gaps increase instability of
  the state of the work.

62
Problems specific to a distributed cooperative
work

• Distribution Related Issues
• In a distributed work, we come across a problem
  of how we should handle a situation in which we
  can not communicate with others. We need to
  provide a mechanism which can assist development
  works in an environment isolated with others.

63
It causes

• A lot of inconsistencies among shared artifacts
  / products and interface definitions produced
  through a cooperative work
• A lot of uncertainties and inconsistencies of
  decisions made through conversations

64
Inconsistencies

• Inconsistencies are defined as the differences
  between some definitions or decisions which
  accidentally happen during the progress of the
  work.

65
Our Approach to the Solution
66
Current State of the Art
Coordination
Awareness
Extracting project state
Active Coordinator with Team Model
CVS logs
Detection of something wrong ( load unbalance)
Influence to work Interfaces Providing context
of the work
Conflict analysis
Java programs
notify
Emails in ML
Extracting deliberation threads
detect
Configuration management Communication management
Future version space
Collaboration
Concurrency
67
Deliberation thread in detail
68
Multi-Party Deliberation Structure
69
Learning on-demand Support

• Active Book
• Content Development
• Evaluation Method

70
Active Book
Communication if necessary
Open dynamic generation
Someone who knows something
update
creation
Up-to-date contents
interaction
Knowledge Server
Can get knowledge easily
Knowledge sources in outer World
some one wants to know something
Convenient time and place
71
Our Web-based Learning System
72
(No Transcript)
73
Appendix 2History of Software Engineering
74
Birth of Software Engineering

• Research on Software Engineering started from
  1968 in NATO conference held in Garmisch
  Germany2, triggered by several failures of big
  software projects
• and has evolved as follows

2 Naur et al. Software Engineering Concepts
and Techniques, Petrocelli/Charter, New York
(1976).
75
1968-1980

• Formation of Software Lifecycle Concept
  establishing technologies for each phase from
  downstream to upstream .

76
Development of Programming Methodologies

• help us make a program with easy-to-test and
  easy-to-change structure
• Structured Programming by E.W.Dijkstra3
• Parnas Module by D.L. Parnas 4 Information
  Hiding
• JSP by M. Jackson5

3 O.J. Dahl, E.W. Dijkstra, C.A.R. Hoare
Structured Programming, Academic Press, London
(1972). 4 D.L. Parnas A Tecnique for Software
Module Specification with Examples, CACM, 15(12),
(1972), pp.330--336. 5 M.A. Jackson Principles
of Program Design, Academic Press, New York
(1975).
77
Information Hiding or Data Abstraction

• (1) The effects of modifying a data structure is
  scattered over a program. It makes modification
  of a program troublesome.(2) Effects of modified
  data structure is localized, if we can package
  both data structure and related operations in the
  same place of a source code.(3) Information
  Hiding or Data Abstraction, localization of
  change effects(4) Parnas's Module(5) Easiness
  of change of data structures was achieved. (6)
  The same or similar descriptions appear in a
  source code redundantly

78
Development of Design Methodologies

• Composite Design by G.J. Myers6
• Structured Design by E. Yordon and L.L.
  Constantine7

6 G.J Myers Composite / Structured Design, Van
Nostrand Reinhold, Newyork (1978). 7 Edward
Yordon and L.L. Constantine Structured Design
Fundamentals of a Decipline of Computer Program
and System Design, Prentice-Hall, Englewood
Cliffs, N.J. (1979).
79
Development of Programming and Design
Methodologies

• Those results affect the design of programming
  languages like
• Pascal
• C
• Object-oriented Programming Languages.
• Many many tools were developed

80
Description of Users Requirements (requirement
engineering)
?

• ISDOS by D. Teichrow8
• SADT by D.T. Ross9
• SREM by M.W. Alford10

Requirements-mismatch Program with Good
structure
8 D. Teichrow and E. Hershey PSL/PSA a
computer aided technique for structured
documentation and analysis of information
processing systems, IEEE Trans. on SE , 3(1),
(1977), pp.41--48.9 D. Ross Structured
Analysis(SA) a language for communicating ideas,
IEEE Trans. on SE , 3(1), (1977),
pp.16--34.10 M.W. Alford A Requirement
Engineering methodology for real-time processing
requirements, IEEE Trans. on SE , 3(1), (1977),
pp.60--69.
81
70's

• Development of Technical Project Management
  technologies
• Development of Software Engineering Database
  technologies

development support project management
a pair of wheels
82
Development of Technical Project Management
Technologies

• Cost estimation
• COCOMO by B.Boehm11
• Detection of risky factors (software complexity
  measures)
• V measure(cyclomatic number) by R. MaCabe12
• E measure by H. Halstead13
• Estimation of terminating test activities
• software reliability growth model14

83
11 Barry Boehm Software Engineering Economics,
Prentice-Hall, Englewood, (1981).12 T.J.
MaCabe A Complexity Measure, IEEE Trans. on SE ,
2(4), (1976), pp.308--320.13 M.H. Halstead
Elements of Software Science, North-Holland,
Amsterdum, (1977).14 C.V. Ramamoorthy and F.B.
Bastani Software Reliability-Status and
Perspective, IEEE Trans. on SE , 8(4), (1982),
pp.354--371.
84
Development of Software Engineering Database
Technologies

• which support configuration management and
  project management

85
1980-1990

• Formalization and partial automation in upstream

86
Appearance of Prototyping Technologies

• Water fall model paradigm was discarded because
  it turned out to be impossible to define users'
  requirement perfectly. Paradigm sift for software
  development happened from water fall model to
  prototyping15.

15 William.W. Agresti New Paradigms for
Software Development, IEEE Tutorial, IEEE
Computer Society, (1986).
87
Analysis of Dynamic Behavior of Specifications
by Executable Specification

• for feasibility study and requirements
  elicitation based on prototyping paradigm or
  operational paradigm.

88
Examples

• Real-time Data Flow by Paul. T. Ward16
• JSD by M. Jackson17
• PAISLey by Pamera Zave18
• PROTnet by Giorgio Bruno19
• User interface simulation by Anthony I.
  Wasserman20

89
16 Paul T. Ward The Transformation Schema An
Extension of the Data Flow Diagram to Represent
Control and Timing, IEEE Trans. on SE , 12(2),
(1986), pp.198--210.17 M.A. Jackson Jackson
System Development, Prentice-Hall International,
London, (1983).18 Pamera Zave and William
Schell Salient Features of an Executable
Specification Language and its Environment, IEEE
Trans. on SE , 12(2), (1986), pp.312--325.19
Giorgio Bruno and Giuseppe Marchetto
Process-Translatable Petri Nets for the Rapid
Prototyping of Process Control Systems, IEEE
Trans. on SE , 12(2), (1986), pp.346--357.20
Anthony I. Wasserman et. al. Development
Interactive Information Systems with the User
Software Engineering Methdology, IEEE Trans. on
SE , 12(2), (1986), pp.326--345
90
Development of CASE(Computer Aided Software
Engineering) Tools

• CASE tools for SA/SD21( e.g. StP)

21 Meilir Page-Jones The Practical Guide to
Structured System Design, Prentice-Hall
Englewood, N.J., (1988).
91
1985-1995

• Software process model and integrated Environment
• Analyzing and supporting human factors

92
Software Process

• Process programming by Lee Osterweil22
• CMM by SEI23
• SPI(Software Process Improvement) activities

22 L. Osterweil Software Processes are
Software too, 9th ICSE, (1987), pp.2--13.23
Watts S. Humphrey Managing the Software
Processctured System, Addison-Wesley, Reading
Mass., (1989).
93
Integrated Environments

• Tool Integration by PCTE24

24Lois Wakeman and Jonathan Jowett PCTE -- The
Standard for Open Repositories, Prentice-Hall
Englewood, N.J., (1993).
94
Analyzing and Supporting Human Factors

• Protocol analysis of human factors25
• Communication support for consensus making and
  informationexchange26

25 Bill CurtisHuman Factors in Software
Development, IEEE Tutorial, IEEE Computer
Society, (1986).26 Colin Potts and Glenn Bruns
Recording the Reasons for Design Decisions,
10th ICSE, (1988), pp.418--427.
95
1985-2002

• Object-Oriented Technologies
• Distributed Computing
• Open source software development
• Web Engineering

96
Object-Oriented Technologies

• 1967 Simula by O.J. Dahl27 class and
  instance
• 1977 CLU by B. Liskov28 abstract data
  type
• 1981 Smalltalk80 by Xerox
• 1986 Objective-C by Cox, C by Strusrup
• 1988 Eiffel by B. Meyer
• 1989 CLOS by Moon
• Now Java

28 B. Liskov and S. Zilles Programming with
abstract data types,SIGPLAN Notices,9(4),
(1974),pp.50--60.
97
Abstract Data Type or Class

• (1) The same or similar descriptions appear in a
  source code redundantly, i.e. we should write
  code for each instance, if we realize the
  information hiding principle without type
  definition.(2) We can modify a code only once by
  defining a Parnas's Module as a type
  definition.(3) Abstract Data Type (4) New
  Languages(e.g. CLU )(5) There are lot of similar
  class definitions in a source code.

98
Object-Oriented Technologies(object oriented
analysis and design)

• 1986 OOD by G. Booch29
• 1988 Shlare/Mellor,
• 1991 Coad/Yordon,
• 1991 OMT by J.Rumbaugh30
• 1995 OOSE by Ivar Jacobson31
• now UML32,33,34

99
29 Grady Booch Object Oriented Design with
Applications, The Benjamin/Cummings Publishing
Company, (1991).30 James Rumbaugh et. al.
Object-Oriented Modeling and Design,
Prentice-Hall Englewood, N.J., (1991).31 Ivar
Jacobson et. al. Object-Oriented Software
Engineering -- A Use Case Driven Approach, ACM
Press, (1992).32 Ivar Jacobson, James
Rumbaugh, Grady Booch The Unified Software
Development Process, Addison-Wesley, (1999).33
James Rumbaugh, Ivar Jacobson, Grady Booch The
Unified Modeling Language Reference Manual,
Addison-Wesley, (1999).34 Grady Booch, James
Rumbaugh, Ivar Jacobson The Unified Modeling
Language User Guide, Addison-Wesley, (1999).
100
(No Transcript)
101
Appendix 3Current Topics in Object-Oriented
Technologies
102
Current Topics in Object Oriented Technologies

• Design patterns by GoF35
• Application Frameworks36
• Software Components37
• Distributed Computing and Middleware such as
  RPC, RMI, CORBA

103
35 Eric Gamma, Richard Helm, Ralph Johnson,
John Vlissides Design Patterns, Addison-Wesley,
(1995).36Ted Lewis et. al. Object Oriented
Application Frameworks, Manning Publications,
(1995).37 Clemens Szypersky Component
Software -- beyond object-oriented programming,
Addison-Wesley, (1997).
104
Achievements and Issues
Achievements
Easy-to-change of Data Structure (Information
Hiding) Programming-to-difference
(Class Inheritance) Easy-to-evolve
(Interface inheritance)
Topics
Coarse-grained Reuse ( Design Patterns,
Frameworks) Distributed Computing ( Middleware,
Component-ware)
105
Relationships
Independent
System Development path
Architectural styles
Frameworks
Design pattern
New Framework development
Domain dependency
Domain models
Kits
Kits Development
Detailed
Domain taxonomy
Applications
Implementation
Abstract(natural languages or diagrams)
Concrete(machine readable)
38W.M.Tepfenhart and J.J. Cusick,A Unified
Object Topology, IEEE Software Jan/Feb.
pp.31-35,1997.
106
Design Patterns

• (1) Experienced object-oriented designers know
  something inexperienced designer don't. What is
  it ? (2) Such technologies as Interface
  inheritance(or sub-typing) and overriding, object
  composition and delegation are more useful for
  promoting reuse. Experienced designers know
  useful recurring patterns which give us common
  design terms.(3) Design Patterns(4) Micro
  architectures (five Creational Patterns, seven
  Structural Patterns, eleven Behavioral
  Patterns)(5) It is difficult to develop useful
  design patterns.

107
Observer
ConcreteSubject notifies its observers whenever
a change occurs that could make its observers
state inconsistent with its own. After being
Informed of a change in the concrete subject,
ConcreteObserver uses this information to
reconcile its state with that of the subject.39
Observers
Observer Update()
Subject Attach(Observer)
Detach(Observer) Notify()

for all o in observers o -gt Update()
Subject
ConcreteSubject subjectState
GetState()
ConcreteObserver ObserverState Update()
observerState subject-gtGetstate()
return sujectstate
39 Erich Gamma, Richard Helm, Ralph Johnson,
John Vlissides, Design Patterns,
Addison-Wesley Publishing
108
Application Frameworks

• (1) The lifecycle of a program become shorter and
  shorter. It is difficult to develop a program
  from scratch even if we use object-oriented
  approach.(2) If we can provide a set of
  cooperating objects that make up a reusable
  application-independent implementation, We can
  create a particular application by customizing
  it. Customization is realized by creating
  application-specific objects and just add-on them
  to the framework.(3) Application Framework(4)
  San Francisco Framework(5) We need to prepare an
  application framework for each domain.

109
Three-layered Architecture
Penker, UML Toolkit, Wiley Computer Publishing,
1998 Hans-Erik Eriksson and Magnus.
two-layered
Three-layered
Four-layered
Presentation layer(GUI)
Application layer
Application logic layer
(collection of Façades for each presentation)
Application layer
Business object layer
Business object layer
Database Package
DB Interface layer
DB Interface layer
DB Interface layer
SQL Generator Package
ltltFaçadegtgt ObjectToRelational Translation Package
110
Component-ware

• (1) The lifecycle of a program become shorter and
  shorter.(2) We want to have technologies that
  support plug-in and play development using
  components which encapsulate application domain
  knowledge.(3) Component-ware(4) JavaBeans(5)
  Unreliability of components affects traditional
  management technologies wrt. reliability
  management and process management. We need new
  software development methodologies and management
  technologies.

111
Middleware

• (1) Applications working over a network is
  increasing. We should prepare environments which
  can support communication between remote objects
  in a heterogeneous computing environment.(2)
  Communication support between remote objects by
  stub and skeleton(3) middle ware (4) CORBA(5)
  Programming effort is still heavy and tedious

112
CORBA
Interface aa long print(in string data)
IDL definition
IDL compiler
Client Application
Server Application
IDL stub
IDL skeleton
Dynamic Invocation Interface
Object Adaptor
ORB Interface
Interface Repository
Implementation Repository
ORB core