Advanced Object-Oriented Modeling Techniques for Large Scale Systems

Copyright © IFAC Large Scale Systems. Rio Patras . Greece. 1998

ADVANCED OBJECT-ORIENTED MODELING TECHNIQUES FOR LARGE SCALE SYSTEMS

Dr. habil. se. ing., prof. Janis Osis

Bikernieku iela. 77-3../. Riga-U"]039. Latvia: em ail: oSis.a.egle.cs. rru.lv

Mag. se. ing. Oksana h 'asiuta

1eriku iela. 58-169, Riga-L VJ084, Latvia; email: ivasiutaCiiiegle.cs. rtu.lv

Mag. se. ing. Pavels Rusakovs

lurmalas gatve 93/2-54, Riga, LV-J 029. Latvia; email: rusakovs(ii).eg le.cs.rtu.lv

Abstract - Some basic concepts of Demeter kernel method, Object Modeling Technique and Unified Modeling Language and effective features of modern object-oriented prograrruning languages (Ada'95. Java, C++) are discussed in this paper. Each mean is described as an opportunity analyze, design and implement a large scale systems bv using an object-oriented approach . Copy right If! J998 JFAC Keywords - classification, object-oriented techniques, mode ling, implementation, packages.

of thinking and not a programming technique. it can serve as a medium for specification. analysis and interfacing. as well as for programmmg.

1. INfRODUCTION Object-oriented (00) modeling and design is a new way to represent large scale system model. 00 approach promotes better understanding of requirements. cleaner designs. and more maintainable systems (Rumbaugh. 1991). 00 system development refers to the front portion of the software life cycle analysis. design and implementation. 00 models are useful for understanding problems. modeling enterprises. preparing documentation. and design programs and databases . 00 approach allows to design system model at a higher level of abstraction (Booch 1991 ). This introduces features not available 10 conventional programming languages, such as inheritance and class abstraction. 00 approach is a conceptual process independent of a programming language until the final stages. It is a new way

2. DEMETER METHOD In 00 data mode ling, each entity of the problem domain is represented by a set of objects with relations and operations. Two kinds of class decomposition. shown in f Ig J. (Osis and Ivasjuta. 1997) are used. to express the structure of the objects in the Demeter method (Lieberherr and Xiao, 1993): I) decomposition into subclasses. it describes the kind-oflis-a and inheritance relations between classes: 2) decomposition into partclasses on a lower level of partitioning: it describes the part-of relationships with other objects. 787

abs[ro("f

po..rt-o/ Na.".

-

attributes

ooerat lons

_ __

-<>

~ Ch.an~ of l

System I S functioning

dUf!

te

attributes ooeratlons

Fault tolerance mecha nrsrr.

the parameter

attnbutes

attTlbutes

~l_.J:", ~ ____

operations _

•

-- a.s.sOCIQllon " ,

i

/\

dtl1t1c1s

Abnorma l

Normal system functioning

~~ change of

change of the

Abnormal

system

chilnge of the

function ing

attn butes

artnbutes

~;~bu~:;

¥~bue::;

, p .. nmeter

operations

operations.

operations

operations

the

--" -~-----conc r rtr c/ asSl'S Fig. l . Class dictionary graph for a diagnostic task of technical devices.

Fig.2. Class diagram for a diagnostic task of technical devices.

There are two kinds of vertices drawn in the graph (Fig. I. ):

graphically is represented by class diagrams (an example is shown in Fig.2) containing object classes (Osis and Ivasiuta. 1997).

•

the vertices for concrete classes. which Generalization and inheritance are fundamental concepts in 00 languages. Generalization enables the developer to organize classes into a hierarchical structure based on their similarities and differences and provides the means for refining a super class into one or more subclasses. The superclass contains features common to all classes: the subclasses contain features specific to each class. Inheritance may occur across an arbitrary number of levels where each level represents one aspect of an object. Inheritance is an object-oriented mechanism that permits classes to share attributes and operations based on a generalization (Rumbaugh. 1991). An object accumulates features from each level of a generalization hierarchy.

can have direct instances (drawn as D): during the programming process they serve to provide implementations for the interfaces: • the vertices for abstract classes. which have no direct instances (drawn as 0): during the programming process. alternation classes serve to define interfaces (i.e. perform the role of types). In standard 00 terminology here is described the accepted object-oriented programming rule "inherit only from abstract classes" (Lieberherr and Xiao. 1993). The basic construction III the Demeter is method. class dictionary graph. complemented by propagation patterns to define operations for implementation stage in the system developing.

Classes are arranged into hierarchies sharing common structure and behavior and are associated with other classes. Additional constructs for mode ling associations include: link attribute. role. qualifier. and aggregation.

3. OBJECT MODELING TECHNIQUE The Object Modeling technique (OMT) is graphical language. characterized not only by semantics and combines three views of modeling systems (Rumbaugh. 1991).

3.2. Dynamic model

Dynamic models represent those aspects of a system. which are concerned \\-ith time and sequencing of operations - events that mark changes. sequences of events. states that define the conte>-1 for events and states. It captures the sequence of operations that occur, without regard for what the operations perform. what they operate on. or how they are implemented. The dynamic model IS represented graphically by state (Fig.3) .

3.1. Object model

Object models represent the static. structural aspects of a system: object's identity. relationships to other objects. attributes. and operations. The object model provides the essential framework into which the dynamic and functional models can be placed and

788

~y~~e;

Data S tor e

t::nCllonmg

~cificaJlo",

/Defin~d~

Composition of Dau Value:

S ystem . . Functioning /

~eaturo/

Actor

Da ta Fl0'l'

Decomposttlon of Data 'Value: dJ

dJ

compoSIte

~ Sonml Chan8' of h uama" ~\4odei FO rmalton

/~------------~~---------------, :"ormal Objects Functioning ~1odel

/p ~~ .

..

Graph

~:_I/

',

P'una~'

DupUcatJon of Data Value :

/~-;]~

PralSaJlono! I

. (Jraphmodd · "

ChanS!:e of !.arameter

"0<::~) ~IO~ 7~

,

I

./

Fig 4. Functional model notatIOn.

SF and XC I' m o
~~a1S;;~

,

Functioning

control by introducing delays between the creation ~d the use of data. Data flow diagrams show the dependencies between values and the computation of output values from input values and functions . without regard for when or if the functions are executed.

,

"-~_>'Iodel._/

Fig.3.Dinamic model for a fault tolerance mechanism. Each state diagram shows the state and event sequences pennitted in a system for one class of objects. A state diagram is a graph of states and transitions labeled by events. States and events can both be ex-panded into nested state diagrams to show greater detail.

Data flow diagrams are particularly useful for showing the high-level functionality of a large scale system.

3.4. System design and implementation

For example. states "Primary graph model " and '?vormal change of parameter model " are nested into state "Normal objects functioning model"(see in Fig. 3). Events and states can both be organized into inheritance hierarchies. Substates inherit the transitions of their superstates.

The object model describes data structure that the dvnamic and functional models operate on. The operations in the object model correspond to events in the dynamic model and functions in the functional model. The dvnamic model shows decisions which depend o~ object values and which cause actions that change object values and invoke functions . The functional model describes functions invoked by operations in the object model and actions in the dynamic model. Functions operate on data values specified by the object model. The functional model also shows constraints on object values.

Objects are inherently concurrent. Each object is a collection that has its O\\TI state. State diagrams show concurrency as an aggregation of concurrent states. each operating independently

3.3. Functional model

After a problem have analyzed, follows decision how to approach the design . System design includes decisions about the organization of the system into subsystems. the allocation of subsystems to hardware and software components that form the framework for detailed design. The main adyantage of the OMT. is that it gives a possibility to generate program code from graphical representation of the system model. Writing code is an extension of the design process. Writing code should be straightforward. almost mechanical. because all the decision should be already have been made during design. The code should be a simple translation of the design decisions into the peculiarities of a particular language. Decision do have to be made while

Functional models represent those aspects of a system. which are concerned \\ith transformations of values-functions. mapping. constraints. and functional dependencies. The functional model captures what a system does. \\ithout regard for how or when it is done . The functional model is represented by usual date flow diagrams (Rurnbaugh. 1991). The fundamental components of the data flow diagram is shown in FigA. A data flow diagram is a graph of processes. data flows. data stores and actors. Processes transform data values Actors are independent objects that produce and consume values. Data stores are passive objects that break the flow of

789

constitute a system. The use-case diagrams serve to organize the use-cases that encompass system ' s behavior.

\"Titing code. but each one should affect only a small part of the program so that can be changed easy. Nevertheless. the program code is the ultimate embodiment of the solution to the problem. so the way in which it is written is important for maintainability and e:\.1ensibility.

The behavior diagrams define the state. activity. sequence and collaboration diagrams. '
-l UNIFIED MODELING LANGUAGE

The Unified Modeling Language (UML) represents the unification of the Grady Booch. lvar Jacobson and OMT methods (Fig. 5) and is their direct and upwardly compatible successor (Osis and Ivasiuta. 1998). From the inside of view the UML consists of a fonnal metarnodeL a graphical notation and a set of idioms of usage (UML Docum.. 1998) The purpose of the metamodel is to provide a single. common and unambiguous statement of the syntax and semantics of the elements of the UML. The graphical notation constitutes the graphical syntax that humans and tools use to model systems. Most UML diagrams are graphs containing nodes connected by paths. There are three kinds of topological relationships: connection. containment and visual attachment: and four kinds of graphical constructs that are used in the UML notation: icons, 2-d symbols, paths and strings. The UML encompasses a set of idioms of usage that describe common usage (by humans) and degrees of freedom (by tools).

The implementation diagrams (component and deployment diagrams) are derived from Booch ' s module and process diagrams. but they are now component-centered. rather than module-centered and are far better interconnected. The goal of the unification efforts was to keep it simple, to cast away elements of existing methods that didn ' t work in practice. to add elements from other methods that were more effective, and to invent new only when an existing solution. was not available. There are several new concepts that are included in the UML, including stereotypes. responsibilities. threads and processes. distribution and concurrency. activity diagrams for business process reengineering and clear separation of type (UML DOCUffi .. 1998).

From the outside of view the UML defines class diagram, use-case diagram. behavior diagrams and implementation diagrams (UML Docum .. 1998). The class diagrams capture the static semantics of the classes that Booch OODA

.. ~ Statr b"anDtioa

.. .... -.. ............. ..

- -.. _

........

-

.. .

,..... ...

.....

-

... ~ .

i

~

. ....... ~ . --

~

•

- -o---L___

-

0.."

. -~ -

== ==

-aa~s ==~ ---==---C~) )+c::) DynanUc ~odeJ

C!>

Jacobson method ~;c--.

:;;::>

C ) C...) ~) ::::"C;:'

Rurnbaugh OMT

Fig.5.Unification of methods 790

_

implementation of this mechanism "ill be in the future.

5. IMPLEMENTATION TOOLS FOR LARGE SCALE SYSTEMS Three languages of programming may be recommended as potential tools to implement large scale systems. These languages are Ada'95 . Java. and C+-!-. Specific mechanisms of these languages are inheritance. generics and templates and abstraction in classes.

5.3. Abstraction in classes

This opportunity presented in all three mentioned languages. We can construct abstract classes without implementation of problematic methods (data types) during the first steps of programming in this case. and to implement these features of classes in future . Such mechanism closely connected with inheritance. These features will be implemented in future. in really working classes. Abstract classes v.ill be superclasses of hierarchy in this case.

5.1. Inheritance

Ada'95 standard has two new powerful mechanisms for inheritance support: child packages and ragged types. The mechanism of child packages has the follov.ing history. Grady Booch admitted that Ada'83 and C++ don 't have mechanism specialized for large project supporting (for example for large scale systems). New Ada'95 standard includes such support. It is talk about complicated system projecting. based on subsystems. Bertrand Meyer. an expert in Eiffel language. called such systems clusters (Riehle. 1995). The mechanism of child packages lets develop well-encapsulated abstractions as subsystems. by connecting of new packages to those systems (with or v.ithout inheritance). and constructing of more complicated systems from subsystems. Tagged types lets to organize simple type inheritance to unlimited depth. Child packages in inheritance provide great interaction with tagged data types (Osis and Rusakovs. 1997).

6. TABLE OF CO!v1PARlSON Table I shows some distinguishing and similar features of three considering methods. This comparison is based largely on of usage and intuitive experience understanding of techniques. Because measurements are nominal (a method either does or does not have a feature). must be careful when interpreting these finding. The Demeter method is the history of 00 approach and it was an initial effort to apply 00 some aspects. The main disadvantage of the Demeter method is that it describes only structural parts of useful object-oriented data models. Object Modeling Technique is already completely 00 mode ling method and for some time was the best 00 method for creating stable systems, it also is considered in a lot of infonnation sources. UML is not a radical departure from widespread 00 methods. but rather the legitimate successor to all of them. This means that the it is a natural evolutionary step. UML is quite the best method than others because it is derived all of the best features from object-oriented methods and eliminates disadvantages of them.

5. J. Generics and templates It is

necessary also to mention generic packages and functions in Ada'95 and templates in C++. Generic packages and functions appeared even in Ada'83 standard (for their description reserved word generic was ' used). After that. the mechanism of templates was created in C++ (reserved word template). Those mechanisms are effective when the implementation of a version of some common class (subroutine) is necessaI) . to make it more exact. by transmitting of certain types as factical parameters. Such exact versions are good when there are no logical differences in data processing (for instance. in large scale system). and the only problem in using of one and the same methods is different data. It gives an opportunity to make the time of design more short in this case. Java also has reserved word generic. but it doesn't provide am special features . The

7. CONCLUSION The main reason of this search was a grov.ing popularity of object-oriented analysis. design and implementation in recent years. This is e\ idenced by the number of articles and papers published in various journals. conference proceedings. books. and other fonns .

791

Table I . Table of comparison (I - Demeter method. 2- OMT. 3 - UML) Feature name Obj ects : Must have identity and self-contained state and beha\ior Objecr classes: Must define properties of members and must have an e>..1ent Relationship sets: Sets of object associations Aggregation : An abstraction mechanism that represents parr-of relationships Generalization : An abstraction mechanism that specifies inheritance order between classes (is-a relationships) r "alues : Have state. but no behavior or identity .-1 (tributes or merhods: Defines object classes in terms of attributes or methods Abstract classes: Template that define properties. but let no instances be instantiated Dynamic: Method supports system dynamic behavior Functionality: Method supports system functional behavior Full triggers: Can be events alone. conditions alone. or events combined with conditions Actions: Specifies behavior that terminates (Embley. et al .. 1995) Activity. Specifies behavior that may not terminate (Embley. et al.. 1995) Data and event interactions: Let objects both send and receive data and events Interobject concurrency: More than one object can be active at one time Intraobject concurrency: A single object can have two or more threads of behavior active at one time Timing constraints: Provide a means to limit the time required to do something Temporal conditions: Support conditions that reference past. present and future events Metamodel : Defines a valid model instance Generic class: An abstraction mechanism that aids analysis. although sometime thought of as a language feature .i1odules: Group information for design or implementation purpose .Vethod classification : Classifies methods as constructors. destructors. iterators. updaters or accessors Processors: Organize behavior in terms of the computer processors that execute the beha"ior Total number of features

2

3

+

+

+

+

+

+

+

+

+

+ +

+

+ + +

+

+

+ +

+

+

+ +

+

+

+ +

+

+

+ + + + +

+ + +

+

+ +

+ + +

+

+ 8

15

23

Analysis ", 31 st conference MOSIS. voL 1. pp. 37-42. Czech Republic. Osis 1.. Ivasiuta. O. (1998) "Comparison of Advanced Object-Oriented .i1odeling Methods ", 32 nd conference MOSIS. voL 1. pp, 83-90. Czech Republic. Osis. 1.. Rusakovs. p , (1997) "Comparing of Some Object-Oriented Programming Languages ", 31 st conference MOSIS. voL 1. pp. 197-202. Czech Republic. Riehle R (1995) '"Ada 95.' new objectoriented standart". Object magazine. May. 5(2). p.44-48 Rumbaugh. 1. (1991) "Object-oriented modeling and design ", Prentice-Hall, Inc .. New Jersey. .. C'ML Documentation Set Version 1.1 " (1998), at : http://www.rational.com/wnl Embley D .. Jackson R. Woodfield S (1995) "00 S:vstems analysis: Is It or Isn 't It? ", IEEE Software. July ' 95. pp,19-33

The main contribution of this paper is a generalization of separate materials about object-oriented methods. an effort to estimate and compare methods and to give users a general notion about object-oriented mode ling tedmiques.

REFERENCES Booch. G. (1991) "Object Oriented DeSign with Applications" The BenjarninJ Cumrnings. California. Lieberherr. K . Xiao. C (1993) "Formal Foundation for Object-Oriented Data .i1odeling" IEEE Transactions on Knowledge and Data Engineering. Vo1.5. Number 3. pp. 462-478. Osis. 1.. Ivasiuta. O . (1997) "Advanced Methodologies for ObjeCI-Oriented Syslem

792