Engineering Distributed Objects This Page Intentionally Left Blank Distributed Objects Wolfgang Emmerich London Uni. Wolfgang Emmerich Engineering Distributed Objects The pay-offs for creating distributed applications are in achieving portability, scalability and fault-tolerance. Engineering Distributed Objects By Wolfgang Emmerich - [Free] Engineering Distributed. Objects By Wolfgang Emmerich [PDF] [EPUB].
|Language:||English, Spanish, Indonesian|
|Genre:||Fiction & Literature|
|Distribution:||Free* [*Registration Required]|
Emmerich, Wolfgang, Dr. Rer. Nat. E n g in e e rin g d .. 'Engineering Distributed Objects'; it just meant that I had to develop much more elaborate lecture notes. 3 [EMMb] W. Emmerich, Engineering Distributed Objects There are four categories of middleware technologies identified by Wolfgang. Wolfgang Emmerich. Personal web: goudzwaard.info London . Proc. of the ICSE 99 Workshop on Engineering Distributed Objects.
Proceedings will be published by Springer Verlag Are you building applications using distributed-object technology? Are you doing research in distributed object-based systems? Are you using existing distributed-object systems? In other words: are you actively involved in distributed objects and applications DOAs? Consider contributing a practice report or a research paper to this innovative event to present, discuss and obtain feedback for your ideas among other practitioners and researchers active in the same area.
There is agreement among researchers and practioners about the importance and potential of distributed-object systems. These systems offer many promises for use in various applications, including telecommunications, embedded systems, databases, Web services, and so on.
Distributed-object systems offer practical, real-world production solutions to technical problems, including interoperability across different hardware, software, and database platforms. Moving could also be needed due to a change in the access pattern of that component; the component might have to berelocated closer to its users.
We refer to thisremoval of components 3s migration. Migrutiort trunrparelsq refers to the fact that components can be migrated without users recognising it and without designers of client Components or the component to be migrated taking special considerations. Migration transparencydepends on both accessand location transparency. Migration cannot be transparent if the interface of a senice request changes when a local component is moved to a remote host or vice versa.
Likewise, migration cannot be transparent if clients need to know the physical location of a component.
Migrationtransparency and locatlon transparency. On Migration transparency is a rather important property. It isverydifficult to administer a distributedsystem in which components cannot befreelyrelocated. Such a distributed system becomes very inflexible as components are tied to particular machines and moving them requires changes in other components.
We discusshowmigrationtransparencyis achieved in Chapter 9 when we discuss the life cycle of distributed objects. These copies, however,need to be tied together. If theymaintainaninternal state, that state needs to be synchronized in all copies. We refer to copies o f components that meet this requirement as replicus. The process of creating a replica and keepingthe replicas up-to-date with the originalisreferred to as replication.
Replication isused to improve the overall Arepticaisacomponent COPY thatremains synchronized with its original, 4 22 Distributed Systems performance and to make systemsmore scalable. Moreover, ifone replica fails other replicas can stand in. Replication transparency that and programmers do not know whether a replica or a master provides a Replication should be transparent in a distributed system.
Replication transparency refers to the fact that users andapplicationprogrammersare not aware that aservice they areusingis not provided by an "original" master component, but by a replica. Replication transparency also refers to the fact that application engineers who build a component should not have to take into account that the component might be replicated. Italso mcans. Replication depends on access and location transparency, c..
Replication transparencydepends on access and location transparencyin the same wayas migrationtransparency does. Replicasaretypicallyheld on different machines from that which hosts the master conlponent in order to distribute the load. To achievereplication transparency, we need the way that services are requested to be the same for the replica and the master and we must avoid clients needing to know the location of either the replica or the master component.
Without replicationtransparency, the resultingsystems will bedifficult to use and even more difficult to scale to accommodate a growing load. If replication is not transparent for the construction o f components providingaservice, it will not be possible to replicate existing components that have not been constructed to be replicated. This complicatesadministration, as components have to bechangedwhenreplication becomes necessarp.
Hence, multiple components may existand operate concurrently. Concurrency of components, however,shouldbetransparent to users andapplication engineers alike. This definition is rather abstract and it needs to be illustrated with a number of examples. Concurrency transparency that users and programmers are 23 Transparency Systems in Distributed Example 1. Potential implications of integrity violations include incorrect financial accounts, money that is lost during financial transactions or soccer players who are unavailable for important games due to a double booking.
If concurrency were made visible to users, they would recognize that they are not the sole users of the system. They might even see what other users do. This is only acceptable in exceptional cases e. If concurrency control were to be implemented by the application engineers, the construction of applications would be much more complicated, time-consuming and error-prone. Fortunately, there are techniques available so that concurrency control can be implemented in a middleware component in such a way that concurrency can be transparent to both users and application engineers.
We discuss these techniques and the use of middleware systems that implement them in Chapter Scafabifitytramparnrcy denotes another highlevel transparencycriterion and demandsthat it should be transparent to designers and users how the system scales to accommodate a growing load. Scalabilitytransparencyisvery similar to performance transparency in that both are concerned with the quality of service that is provided by applications.
While performance is viewed fromthe perspective of a single request, scalability transparencyconsiders how the system behaves if more components and more concurrent requests are introduced. Thus, the i: I f a system supports replication, we can xalc it by adding more replicas. Moreover, wecanaddnew hosts and populate them with existing components that we migrate from overloaded hosts.
If scalability isnot transparent to users they will beannoyed by degrading performance the as ovenll systemloadgraduallyincreases. There might be situationswhereasystem that functions correctly is rendered unusable because it cannot accommodate the load.
In banking applications, for example, systems often have to complete batch jobs overnight. If they Fail to complete the batch because it is too complex, the bank cannot resume businesson the following day. If scalability isnot transparent to application developers, aconsequence is that the system often its architecture has to bechanged.
These changes tend to be rather expensive. This demands that it is transparent to users andapplicationprogrammershow the systemperformance isactuallyachieved. Whenconsidering performance, we are interested inhowefficiently the system uses the resources available.
These resources can bethe time that elapses between two requests or the bandwidth that the system needs. Again, performance transparency is supported by lower-level concepts asitrelies on replicationtransparencyandmigration transparency. Distributed in 25 Transparency Replication of components provides the basis for a technique called foad bafancitg, which achieves performance transparency.
A middleware system that implements load balancing selects the replica with the least load to provide a requested service. The middleware system shouldperform this balancingdecisionina way that is transparent to both users and application programmers. The performance o f a system can be improved if components that remote accessesareminimized.
This usuallyrequires arerelocated in suchaway migration of components. Achievinganoptimalperformancewould then demandthat accesspatterns to components are monitored and component migration is triggered when necessary. We achieve performance transparencyif the underlying middleware triggers component migration in a way that is transparent to users, application programmers and possibly even administrators. Performance transparency is rather difficult to achieve.
Only a few middleware systems to date are actually capable o f performing load balancing. The reason is that it is genuinely difficult to automatically predictthe load that a component is going to cause on a host in the future. Because of that, achieving good performance o f a distributed system still requires significant intervention of application designers and administrators.
Failure transparency denotes the concealment of faults from users, client and server components. Failuretransparency means that users and programmers are unaware of how distributedsyrtems Hence, failuretransparencymeans that components canbedesignedwithouttaking into account that services they rely on might fail. The same consideration also applies to server components. Failuretransparencyimplies that server components canrecoverfromfailures without the server designer taking measures for suchrecovery.
Asshownin Figure 1. Its achievement is supported by both concurrency and replication transparency. If failureshave to be concealed, wehave to ensure that the integrity of components is not violated byfailures.
Such integrity violations are often due to related updates that are only partially completed. We will see that transactions are used to ensure that related changes to different components are done in an atomic way.
Transactions, in turn, areimplemented based on the mechanisms that achieve concurrency control. We willdiscuss this in Chapter 11 in more detail. In addition to transactions, replicationcan be employed to achievefailuretransparency. Replicascan step in for afailed component andprovide a requested service instead o f the original component.
When this is done ina way that is transparent to users and client components, failures of components are concealed. They I. The design ofthc equity trading packagcs or. Moreovcr, components that provide. If failures of servers are not transparent to designers of client applications, they have to build measures into their clients to achieve failure transparencyfor their users.
This will complicate the design of clients and make them more expensive and difficult to maintain. Key Points b b b Distributed systems consist of a number of networked hosts, each of which mecutes one or several components.
These components use middleware to communicate with each other and the middleware hides distribution and heterogeneity from programmers to some extent. Developers often do not have the choice to develop a centralized system architecture because non-functional requirementsthatincludescalability, openness, heterogeneity, resource sharingand fault-tolerance force them to adopt a distributed architecture.
We havediscusseddifferentdimensionsinwhich distribution can betransparent to users, application designers and administrators. These dimensions are access, location, concurrency, failure, migration, replication, performance and scalabilitytransparency.
These provide design guidelines for distributed systems. The transparency dimensions we identified are not independent of each other. Access, location and concurrency arelow-leveltransparencydimensions. They support higher level dimensions, such as failure, performance and scalability transparency. Self Assessment 1. What is the difference between a client-server system and a distributed system? Is a three-tier architecture a distributed system? Why do we not build every system as a distributed system?
What is the relationship between requirements engineering and distributed systems? What are the eight dimensions of transparency in distributed systems? What can the transparency dimensions be used for? What is the difference behveen location and access transparency?
What are the differences between performance and scalability transparency? Further Reading Engineering distributed systems follows a development process that is not much different from that for other sohvare systems. Throughout this book, we assume that the reader is familiar with basic sohvare engineering principles and techniques. We recommend [Ghezzi et al. A good introduction to object-oriented software engineering is given in [Jacobson et al. Transparency in Distributed Systems The selection of particular distributed system architecturesis often driven by nonfunctional requirements.
The requirements engineeringprocess that precedes the design o f a distributed systemisbeyond the scope of this book and we refer to [Sommenille and Sawyer, as a good reference. Moreover, several sofovare engineeringstandards, suchas those discussed in [Mazza et al.
They define categories of non-functional requirements that influence the architecture of distributed systems. Other textbooks employ a definition of distributed systems that slightly differs from ours. The reader might deepen the understanding of relevant concepts by comparing our definitions with the ones given in [Sloman and Kramer, , [Colouris et al. We will l e a r n about the history of object orientation andhow contributions fromdifferentdisciplines of Computer Science led to distributed objects.
We will study the notations defined in the Unified Modeling Language UML , which we will use to communicate about the design of distributed objects. We will then grasp a meta-model for objects in order to acquaint ourselves with the concepts of distributed objects, such as object types, attributes, operations, inheritance and polymorphism. We will recognize the differences benveen distributed and local objects in order to understand how the design of objects differs when objects reside on different hosts.
Chapter Outline 2. The main constituents of every distributed system are the system components. They offer services to other components, which can request service execution.
In this book, we assume an object-oriented view ofdistributed systems. Hence, we consider the components o f a distributedsystem to be objects. The object-oriented paradigm isawry appropriate modelfor a distributed system. Services can be seenas operations that an object exports. How these objects are implemented is o f no concern and the type of an object is therefore defined by interfaces.
Interfaces may declare the visible state of a component, which can be regarded as a set of object attributes. The concept of references to objects is used for addressing components. Finally, the requesting of a service canbe seen as a remote operation invocation. All aspects of object orientation concepts, languages, representations and products have reached a stage of maturity where it is possible to address complex issues of distribution using the object-oriented paradigm.
We review the evolution of object-oriented concepts in the next section to indicate exactly where wehave now reached. Prior to implementation,all systems necessarilygo through preliminary stagesof more general analysis and design which, in the case of those that use an object-oriented approach, are now facilitated by the aandardized representations offered by the Unified Modeling Language, in particular the diagramsdefinedin the U M L Notation Guide.
We discuss those diagramsin the second section. We then discuss a meta-model relevant to distributed objects in order to provide a framework for explaining basicconcepts, as now generallyunderstood, and a hierarchyfor thinking about how objects are implemented. Once detailed design is underway it is necessary to consider very carefully the differences between centralized and distributed systems and the implications of factors including the life cycle, object references, request latency, security andso on.
We discuss what differentiatesdistributedobject design from local object design in the last section. We can distinguish three strands in object orientation: Although largely independent, several cross-fedizations are indicated by the lines that span the boundary of the strands.
Object orientation startedinScandinaviawith the development of S i u l a [Dahl and Npgaard, Simula is a programming language that was targeted to the development of simulationprograms.
Simulaincludes the concept of aclass,which is a type whose instances can react to messages that are defined by operations. By hiding information about the data structures within a module, other modules cannot become dependent on these modules; they are not affected if data structures have to be changed.
These ideas later 31 Evolution of Object Technology Figure 2. In the late s, the Xerox Palo Alto Research Center conducted research into novel user interfaces for computers and inventedthe ideas of desktops, windows and pointing devices, such as mice or trackballs. I t became clear that existing imperative programming languages were not well suited for applications that needed to react to events in multiple windows.
In response to that problem Smalltalk[Goldberg, was developed as a new programming language that was centred around the notion of an objcct. Objects were applied to many differentproblemsandSmalltalkimplemented the vision that 'everything is anobject'. Objects wereused to implement the functionality of applications, to store dataand to compose the user interface from different components.
Objects were even used to manage the evolution of the set of object types that are defined.
Smalltalkalso included the concepts of inheritance and polymorphism that made it possible to create reusable class libraries, for instance to support user interface management.
Inspired by the success ofSmalltalk, several groups introduced object-oriented concepts into procedureprogramminglanguage,whichled to the creation of hybrid object-oriented languages. The languageleaves a considerable amount of freedom to programmers. Like Smalltalk, it does not have a rigorous type system, it enablesprogrammers to manipulate object references and it lacks powerful memory management.
Eiffel [Meyer, bl was defined to overcome these deficiencies. Contracts arespecifiedinclass definitions that arebinding for client andserver. Class definitionsnot only include static properties ofclasses but also behavioural definitions, such as invariants and pre- andpost-conditions of operations. The success of object-oriented programminglanguagesmotivated the development of notations and a method for applying the object-oriented paradigm in earlier phases o f the development.
At the end of the s and early Os, object-oriented analysis and design OOAD methods were defined inorder to enable the seamless use ofobjects from requirements to implementation. The techniques eachused their own notation for objects and they had a different focus on analysis, design or both.
A consomum led by Rational Corporation, whichemployed Booch, Rumbaughand Jacobson at the time, defined the Unified Modeling Language UML inan attempt to resolve the heterogeneity in object-oriented analysis and design notations. U M L includes a meta-model, a semantics definition and a notation guide. U M L supportsmodelling the structure of systems using class diagrams and object diagrams. It also facilitates modelling the behaviour of systems. Interaction diagrams are used for modelling inter-class behaviour.
State diagrams are used to model intra-class behaviour. Methods now merely differ in how this standard notation is used during the analysis and design of objects. In ONC, clients cancall procedures that run on remote machines. The interfaces of remote programs are specified in a dedicated interface definition language.
Client and server stubs convert complex procedure parameters and results to and tiom a form that is transmissible via network transport protocols, such as TCP or UDP. Stubs are derived by rpcgen, a compiler for the interface definition language. In particular, D C E standardized an external data representation XDR for data types that are used in procedure parameters and results.
By means of XDR, clients can call remote procedures from serversthat have a different data representation. OSF also standardized a number of higher-level services, such as a naming service to locate components andasecurityservice that canbeused to authenticate components. CORBA combines the idea of remote invocation with the object-oriented paradigm. Objects use ORBs to request execution of operations from other objects.
Hence, ORBs provide the basic communication mechanism between distributedobjects. These objectsmay be heterogeneous in various dimensions: Hence, ORBs provide the basic communication mechanisms for distributed and heterogeneous objects. The OMGhas also standardized interfaces for higher-level services and facilities that utilize the basic communication mechanism to solve standard tasks in distributed systems, many of which support achieving the distribution transparency dimensions identified in the previous chapter.
Microsoft defined its Component Object Model COM asan interoperability model for applications that are written indifferentprogramminglanguages. C O M is not l l l y object-oriented, as it does not includemultiple inheritance. C O M objects, however, can have multiple different interfaces and this is used as a replacement of inheritance.
The first versions of C O M did not support distribution. They served as a basis for integrating hcterogeneous objects on the same machine. With the advent of Windows NT4. Distribution primitives are tightly integrated with object-oriented programming language features in Java [Winder and Roberts, Java includes primitives for Remote Method Invocation M I so that a Java object on one machine can invoke methods from a Java object that resides on a remote machine.
RMI also uses stubs and skeletons to perform marshalling, although data representation heterogeneity does not have to be resolved. We have now verybriefly sketched the evolution of object technology. Several of the concepts that we could only touch on here willhave to be revisited throughout the rest of the book. The use of these middlewaresystemsrequiresdetailedknowledge of the underlying object-oriented concepts as well as object-oriented design notations.
We will focus on them in the remainder of this chapter. A notation is defined in terms of syntax and semantics. The syntactic part of the notation can be determined in terms of a grammar, be it for a textual or a graphical language.
The semantics of a language can be distinguished in static and dynamic respects. The static semantics typically identifyscope and typing rules, such as that declarations of identifiers must be unique within a certain scope and that applied occurrences must match particular declarations.
The dynamic semantics defines the meaning for different concepts of the notation. U M L is a notation for object-oriented analysis and design. U M L consists of a meta-model, the definition of the semantics of concepts identifiedin the meta-model, anda notation guide that identifies different diagram types that utilize the concepts of the meta-model.
The purpose of this section is to introduce a standard notation for communication about objects. We do so by focussing on the diagram types and their usein the process of engineering distributed objects.
For each ofthem, we discuss its purpose, indicate the main concepts that are available and briefly and informally indicate the semantics of these concepts. A use case is a generic description of anentire course of events involving the systemand aCtOE external to the system. Use casediagramsareproducedduring the requirementsanalysisstage o f the system development.
A use casediagram see Example 2. Analysis begins with the identification of actors external to the system. An actor is a generic way ofdescribing thepotential users of the system. Actors are represented as stick persons in usecasediagrams. In identifying actors, wewill need to consider scenarios or situations typical to the system andits use.
Note that the users arenot necessarily human;they may also be external systemsthat use an application through its system interfaces. Am e r important distinction is between actors andusers. Actors are types while users denote particular instances of these types. A use cme is depicted as an oval in a use case diagram. The description of the use case is associated with that diagram. Together the use cases in a diagram represent all the defined ways of using the system and the behaviour it exhibits whilst doing so.
Again, we separate types and instances for use cases. Each usecase is a specific type for how the system is used. When a user an actor instance inputsa stimulus, the scenario executes and starts a function belonging to the use case. These interactions are recorded in the usecase Actors interact withcertainusecases.
Interactions alsoidentifywhich types of user have astakein the functionality that is embedded in a use case. Interactions are depicted as lines. The identification of interaction between actors and use cases is an important step for the engineering of a distributed system.
Actors will need an interface to the system. If actors represent humansthey will need a user interface. If they represent external systems, they will need a system interface. In both cases, the interface may need distributed access to a use case. The user interface might be deployed on the web, for instance, and then the user should be able to interact with the system from a browser running on a remote machine.
Likewise, the external system might be running on a remote host and should be able to access the use case remotely. A scenario can be seen asparticularexample of ausecaseandassuch it is more concrete. Scgumce diaJrams are a graphical notation that can be used for modellingscenarios. Example 2. A sequence diagram depicts objects that partiapatc in the scenario and the sequence of messages by means of which the objects communicate.
Sequencediagrams interaction obiem in a sequential model scenarios between fashion. B o r u s s i a , Teddy and Stefamand anonymousOutput.
Objects in a sequence diagram are displayedas rectangles. The annotation in that rectangle consists of an optional object name and a type identifier, separated bp acolon.
The annotation of objects is underlined in order to indicate the difference fiom classes, which are also represented as rectangles. Objects have lifelines that indicate their lifetime. The lifeline is a vertical dashed line that starts at the rectangle. T h e cross at the bottom of the O u t p u t object lifeline indicates that the object ceases to exist at that point in timc.
Messages are sent from a client Object to a server objectto request Sequence diagrams can be during and design. Messages that are sent fromone object to another are shown as horizontal arrows. They are given names that usually correspond to operations of the target object.
An arrow with a complete arrowhead shows a synchronous message. In the example, b o o k G o a l i e s is a synchronous message that the trainer of the goalkeepers would send to the team object. Filled arrowheads indicate local messages that are implemented as procedure calls. T h e book messages that the team object sends to the two players who are goalkeepers are examples of those.
Messages are ordered in time. Arectangular represents the activation of the object.
Activation corresponds to a period when the object performs an action, either directly or by sending a message to another object. The top of the stripe indicates the beginning of activation and the bottom shows when the object is deactivated. The use of sequence diagrams is not confined to requirements analysis.
Sequence diagrams are also extremely useful to show designscenarios. During analysis, sequence diagrams show what happens in a scenario. These implementation scenarios are usedto validate the design and to see whether use cases can actually be implemented with the functionality defined in the design class diagram. Classdiagrams Class diagramsdefine define object types in terms of attributes, operations and the associations between objects.
Class diagrams model attributes, operations and associations. The concerns addressed by class diagrams include the visibility of attributes and operations, the type of attributes and the signatures o f operations, the cardinality of associations andthe like. Class diagrams are astatic modelling tool and do not determine dynamic aspects of classes, such asthe algorithms ofoperations.
A class diagram is shown in Example 2. The main building blocks of a class diagram are clmes. A class represents an object type. Classes are shown as rectangles. These rectangles may be divided into three compartments. The top compartment shows the name of the class, the middle compartment identifies the attributes supported by the class and the bottom compartment declares the operations of the class.
The attribute and operation compartments maybe omitted for reasons of simplicity. U M L class diagnms support the information hidingprinciple.
Public declarations are freely accessible from outside the class. Private attributes and operations areshownusinga -. Private declarations cannot be accessed from outside the class scope.
Thevisibility of Type and subtype relationships between classes are modelled in U M L class diagrams using genwulizationr. They arerepresentedas an arrowwithawhitearrowhead. The class to A type may generalize attributescan be public or private. The existence of generalizations motivates athird category of visibility. Protected operations and attributes are only accessiblefrom within the class and any specialized class. Protected declarations are preceded by a.
In the example, this means that Operations inside the scope of class Club canaccess the inherited name attribute, as its visibilityisdeclared protected inclass Organization.
Associations are shown using lines and they may be given a name. Associations model the fact that one class is related to another class. Most associations are binury, which means that they connect two classes. Associations are the most general form o f relationship. An UMYCgution isanassociation that indicates that objects areaggregates of other objects. Aggregation relationships have adiamondat the object that forms the complex object from its aggregates. Composition associations are stronger form of aggregations and they determine that the component fully belongs to the composite.
This means that there can be only one composite for every component. A filled diamond indicates such a composition. Associationsconnect and have aggregation or compositionsemantia.
Objects 38 Designing Distributed Objects Example 2. A dependency indicates that a class depends on anotherclass. This dependencyisoftencreatedbythe use of object types in attributes, arrows. Dependency associations are represented as dashed They start at the dependent class.
The cardinality determines in how many instances of aparticularassociation an object can participate. A cardinality of zero means that participationin the associationis optional. Associations may have We note that classdiagramsareusedinseveral circumstances during the engineering of distributed objects.
Class diagrams are used during the analysis stage when they determine the relevantproperties of objects. In these classdiagrams, theobject types are modelled from the perspective of what the supported system should do. Class diagrams are also used during the design stage to define the interfaces ofdistributed objects. As distributedobjects are often composed o f many localobjects, class diagramsmay also be usedfor the design of server object implementations.
Class diagramsareused to capture t Y d e v e t abstractions in both the and designof distributed objects. In practice, a class design of a distributed system may have to define several hundred object Packages are used to and types. In order to manage the resulting complexity, some structuring mechanism is needed design information in a for class diagrams.
Puckugcr provide such a structuring mechanism. Packages can be used to hierarchical manner. A package is represented in a class diagram as a folder. Each package is represented by a class diagram at the level below. They express the static part of aninteraction diagram and we will occasionally use them for this purpose in this book.
An object diagram shows objects, which are instances of classes. Objects are represented as rectangles. In order to highlight that these rectangles represent objects, rather than classes, we underline the content of the first compartment, which shows the name and the type of an object. These two are separated by a colon, but if it is not important, the name can be omitted. Object diagrams show examples Of instances Of classes.
Unlike in a class diagram, where the name, type and initialization are shown, the attribute representation in an object diagram only shows the name and the current value of the attributes.
Because it is not necessary to specify the operations o f objects they are all specified in the classes of the object , therectangles in object diagrams generallyonly have nvo compartments. Finally, object diagramsmayshowlinksthat interconnect objects. A link isan instance of an association. A s such, it needs to meet the constraints of the association, suchas the cardinality.
UML state diupzmr model the dynamic behaviour of objects. State diagramsprovidesupport for describing the temporalevolutions of objects in response to interactions with other objects. This isachievedbymodelling the various states o f an object and identifying possible transitions between these states.
State diagrams in UML are essentially equal in power to statecharts, which were first introduced by [Harel, Harel extended the notion o f finite state machines by composite and concurrent states. These extensions avoid the explosion in the number of states and transitions that are known from finite state machines.
The representation of statecharts in state diagrams takesthe form o f a collection of rounded rectangles the states and directed edges the transitions.
Each state diagram is associated with one class. It models the states that instances of the respective object type can be in. Note that not all classes need a state diagram. They are only required if classes modelobjects that maintain a state insuchawaythat the order inwhich operations may be executed depends on those states. The transitions between states may be annotated.
By convention, these annotations have two optional parts that are separated by a slash. The first part is acondition, which is given in square brackets. In case of teams, it is assumed that both students work together on every project, rather than splitting the workload. Remember, the idea is to do pair programming! I will not enforce this, but I expect that the individual's contributions to the projects will be reflected in the midterm and exams.
A word of warning: I will not accept whining about personal issues within teams or late homework excuses related to this. It is your choice and responsibility to decide whether to team up or not. My advice: don't team up unless you trust your partner is as committed as you are in learning the material and delivering the homework on time. Academic Honesty I trust all students are honest and do not cheat. Those who break my trust at any point will get an F in the course - no excuses or apologies will be accepted.