Tutorial at Caise'2003, Velden, Austria

CAiSE 2003 Tutorial 23-April-2003

This presentation is based on: Developing Maintainable Systems – This presentation is based on: Roundtrip Engineering with Metrics Maciaszek, L.A. (2001): Requirements Analysis and System Design. Developing Information Systems with UML, Addison-Wesley, 378p. {translated to Chinese, Russian and Italian}

forthcoming 2nd edition of the above: Tutorial Maciaszek, L.A. (2004): Requirements Analysis and The 15th Conf. on Advanced Information Systems Engineering CAiSE’03 Systems Design, 2nd ed., Addison-Wesley, ~500p. Velden, Austria, 17-June-2003 forthcoming new textbook: Leszek A. Maciaszek, Bruc Lee Liong Maciaszek, L.A. Liong, B.L. and Bills, S. (2004): Macquarie University, Sydney, Australia Practical Software Engineering. A Case-Study Approach, Addison-Wesley, ~600p. © L.A.Maciaszek, B.L.Liong & Addison-Wesley © Addison-Wesley CAiSE 2003 Tutorial 2

Topics The tutorial themes

Application design objectives - PCMEF “Applications come and go. Databases stay for ever.” Tutorial case study – Email Management

System Bob Epstein, Sybase (quoted from memory) Dependency management “Enterprise applications often have complex data – Generic architectural patterns and lots of it – to work on, together with business Architectural patterns for business objects rules that fail all tests of logical reasoning.” The supportability metrics “The architectural pattern I like the most is that of Conclusions layers…” Martin Fowler (in “Patterns of Enterprise Information Architecture”)

Application design objectives MVC

a hierarchical layering of software modules that reduces complexity and enhances Application Program understandability of module dependencies by disallowing direct object View intercommunication between non- Database and Web Services neighboring layers, and Model an enforcement of programming standards Persistent that make module dependencies visible in Data compile-time program structures and that Controller forbid muddy programming solutions utilizing just run-time program structures

PCMEF application packages

<> Meaning of P-C-M-E-F presentation The Presentation package • classes that define UI objects

<> The Control package control • classes responsible for the program’s logic, algorithmic solutions, and main computations The Mediator package <> • creates a level of independence between entity and foundation domain and between control and foundation PCMEF entity mediator • responsible for object caching Database and Web The Entity package Services • classes representing “business objects” <> Persistent The Foundation package foundation Data • responsible for all communications with the persistent data store

Consider non-PCMEF design ...and PCMEF design

CControl EEntity

CControl MMediator

PPresentation MMediator

PPresentation EEntity FFoundation

FFoundation

PCMEF principles PCMEF+

Downward Dependency Principle (DDP)

Upward Notification Principle (UNP)

Neighbor Communication Principle (NCP)

Explicit Association Principle (EAP)

Cycle Elimination Principle (CEP)

Class Naming Principle (CNP)

Acquaintance Package Principle (APP)

Tutorial case study Display email messages

EM – Email Management system • part of an Electronic Document Management System • capture, indexing, classification and retrieval of all email business correspondence Composing and emailing of messages stored in the database and scheduled to be sent to contacts (customers) • a Java application that accesses an Oracle database via JDBC • upon employee’s login to the database, the application can retrieve from the database and display the list of messages to be emailed to contacts • the employee can then email chosen messages • after a successful email, the database is updated accordingly • the employee can create, update, delete messages • messages can be sorted and filtered

Update email message Email received

Conceptual class model Relational database model

Class Let’s slow down and revisit… model for EM Architectural design is an exercise in managing module dependencies • Module A depends on module B if changes to module B may necessitate changes to module A

It is important that dependencies do not cross dependency firewalls (Martin, 2003) • In particular, dependencies should not propagate across non-neighboring layers and must not create cycles

Proactive and reactive approach Packages

Architectural design takes a proactive approach to dependency relationship B owns X A depends on B managing dependencies in software. • This is a forward-engineering approach – from design to Package B Package E implementation. Package A Class X • The aim is to deliver a software design that minimizes dependencies by imposing an architectural solution on + package with no members revealed programmers. circle-plus notation

Package F Proactive approach must be supported by the Package C E owns F reactive approach that aims at measuring F owns Y and Z dependencies in implemented software. Package D + • This is a reverse-engineering approach – from implementation to design.

• The implementation may or may not conform to the Class Y Class Z desired architectural design. C owns D

Cycles between packages Eliminating cycles between packages

Package A Package B

circularly-dependable Package A2 elements of Package A extracted into Package A2

Package C Package D Package E Package C Package D Package E

circularly-dependable Package C2 elements of Package C extracted into Package C2

<> <> Layer Layer 1 Layer 1 Package A Package B dependencies Package A Package B Class X Class Y

Layer 1 Package A depends on depends on Package B because Class Layer 2 X depends on ClassY

<> Layer 2 Class <> Layer 2 Layer 1 depends on Layer 2 because Class X Package C Package D depends on Class Y depend- Package C Package D

encies Class Z

Package E Package E

Method dependencies Method dependencies and delegation

control control public class EOutMessage { EEmployee emp; CActioner CActioner p ubl ic void d o2() { emp.do3(); do1() entity } public class EOutMessage { EOutMessage EEmployee emp; do1() } public void do2() { public class CActioner { emp.do3(); 0..1 EEmployee emp; do2() } public void do1() { } emp.do3(); } public class EEmployee { public class CActioner { entity } EEmployee MBroker brk; EEmployee emp; public void do3() { public void do1() { brk.do3(); do3() } emp.do3(); Act Emp EOutMessage 0..1 mediator } } } do2() MBroker

0..n OutEmp do3()

foundation EEm ployee public class MBroker { public class FUpdater { FUpdater upd; FUpdater public void do3() { 0..n public void do3() { // code for do3 do3() upd.do3(); do3() } } } }

Interfaces UML notations

In the UML 2.0, interface is a declaration of a set of features that is not directly instantiable, i.e. no objects of it can be directly created. The object that implements interface provides “a public façade that conforms to the interface specification” (UML, 2002, p.123). <> In UML 2.0 interface can declare attributes, not just Interface1 Interface3 operations. Interface2 • By contrast, in Java an interface can contain data members but they must be constants (defined as static and final). An abstract class is a class that contains at least one method, which is not (or cannot be) implemented by that class, and therefore it cannot be instantiated. • A class is a class is a class. In languages that support only single AbstractClass1 Class1 implementation inheritance, like Java, a class can only extend one base class (abstract or concrete), but it can implement multiple interfaces. This is a huge practical difference. • The related difference is that interfaces allow passing objects typed as interfaces in method calls.

Implementation dependency Usage dependency

This is permitted in UML 2.0, but not in Java, which only allows extension inheritance between interfaces

public interface Interface1 { private int a1; Interface1 Interface2 public void o1(); a1 a2 } Interface1 <> Interface2 o1() o2() a1 a2

public class Class1 o1() o2() implements Interface1, Interface2 { public void o1() { //implementation code <> } Class1 Class2 public void o2() { public class Class1 { //implementation code Class1 Interface1 myInterface; } public void do1() { } myInterface.o1(); do1() } }

Cycle… and breaking it

public class PPrimaryWindow public class CInit { implements control.ICPresenter { public interface PController { ICPresenter presenter; <> <> public void do2() { public void do2(); public void do1(){ //implementation code } presentation control public class CInit { presenter.do2(); } PPrimaryWindow window; } PPrimaryWindow CInit } public void do1() { } window.do2(); do2() do1() } } <> <> control PDialogBox CActioner presentation PPrimaryWindow <> CInit do3() do4() ICPresenter do2() do1() do2()

public class PDialogBox { public class CActioner{ CActioner actioner; public void do4() { public void do3() { //perform some actions PDialogBox CActioner actioner.do4(); } } } } do3() do4()

Event processing Dependencies in event processing

Synchronous messages need to be considered separately In a callback, the publisher has no knowledge or from asynchronous communication where methods are “fired” to service asynchronous events. interest in how the subscriber processes the event. In event processing there is a separation between an event The dependency exists but it is negligible from the originator (publisher object) and various event listeners/observers (subscriber objects) that want to be viewpoint of the architectural design. informed of an event occurrence and take their own, The hand-shaking of subscribers and publishers presumably different, actions. causes a stronger dependency. In large systems, a separate registrator object performs the subscription, i.e. the “handshaking” between the publisher and • If a registrator object mediates the hand-shaking, then it subscribers. depends on both the publisher and the subscriber. Usually, the publisher object creates an event object –the • If a subscriber object registers itself, then it depends on publisher translates the intended meaning of the event into an event object (called something like BCommandButtonEvent). the publisher. The event object is passed (in a callback operation) to all • To loosen dependencies due to hand-shaking, subscribers subscriber objects that registered their interests in the mouse can be passed to the registration methods in arguments click on the button. typed as interfaces.

public class PConsole { CActioner act; <> PDisplayEvent evt; Acquaintance presentation public void addDisplayEventListener (CActioner actioner) { act = actioner; event object PDisplayEvent } public void removeDisplayEventListener() { Acquaintance defines a situation when an act = null; } object is passed another object in an PConsole private void fireDisplayEvent() { if(evt == null) evt = new PDisplayEvent("Display is changed"); publisher object addDisplayEventListener() if(act != null) act.processDisplayEvent(evt); argument to its method. removeDisplayEventListener() } public void do1() { fireDisplayEvent() doSomething(); More precisely, an object A gets acquainted do1() doSomethingElse(); fireDisplayEvent(); } } with object B if another object C passes B to registrator PDisplayEventRegistrator object A in an argument of the message to A. initialize() public class PDisplayEventRegistrator { PConsole console; CActioner actioner; public void initialise() { Object communication due to acquaintance console.addDisplayEventListener(actioner); } } is one of the programming techniques <> control public class CActioner { legitimized in the Law of Demeter. subscriber CActioner public void processDisplayEvent(PDisplayEvent evt) { object System.out.println("Display event received"); } processDisplayEvent() } © Addison-Wesley CAiSE 2003 Tutorial 37 © Addison-Wesley CAiSE 2003 Tutorial 38

void initializeDisplay() { EEmployee emp = retrieveEmployee(); browser.displayEmployee(emp); Interfaces and acquaintance void displayEmployee(EEmployee emp) { Interfaces and acquaintance } System.out.println("Name:" + emp.getName()); } <> control <> CAc tioner control <> <> presentat ion retrieveEmployee() : EEmployee presentation CActioner initializeDisplay() : void PEmpBrowser PEmpBrowser retrieveEmployee() : EEmployee <> initializeDisplay() : void displayEmployee(emp : IPEmployee) displayEmploy ee(emp : EEmployee)

<> CActioner retrieves EEmployee object and ICEmpBrowser passes it to the PEmpBrowser object. PEmpBrowser is now acquainted with EEmployee and sends messages to it to get displayEmployee(emp : IPEmployee) : void employee data for display.

IPEmployee

getName() : String <> <> domain domain

entity entity

EEmployee EEmployee

getName() : String getName() : String

void initializeDisplay() { IAEmployee emp = retrieveEmployee(); <> browser.displayEmployee(emp); control } Façade pattern void displayEmployee(IAEmployee emp) { CActioner System.out.println("Name:" + emp.getName()); } retrieveEmployee() : IAEmployee initializeDisplay() : void

<> presentation

PEmpBrowser acquaintance displayEmployee(emp : IAEmployee) <>

PEmpBrowser uses IAEmployee for IAEmployee downward access to EEmployee in Acquaintance a non-neighboring package getName() : String getDepartment() : String

<> package <> domain

<> entity EEmployee IAEmployeeWithSalary

getSalary() : int

FUpdater uses IAEmployeeWi thSalary for <> upward access to EEmployee

<> foundation public void saveEmployee(IEEmpWithSalary emp) { FUpdater db.save("Name:"+emp.getName()); db.save("salary: "+emp.getSalary()); } saveEmployee(emp : IAEmployeeWithSalary) © Addison-Wesley CAiSE 2003 Tutorial 41 © Addison-Wesley CAiSE 2003 Tutorial 42

Abstract Factory pattern Chain of Responsibility pattern

Observer pattern Mediator pattern

Class design for EM Instantiation model

Architectural patterns

Identity Map Data Mapper • Load – check-out • Unload – check-in Lazy Load “Email • Lazy Initialization • Virtual Proxy Message” • OID proxy – Navigation in Identity Map interactioninteraction – Navigation in Entity Classes Unit of Work

Identity Map pattern control package : give me entity object activity CAdmin (e.g. EContact) Class EIdentityMap - fragment 18: public class EIdentityMap { object flow object mediator package : 21: private Map OIDToObj; //OID -> Obj MDataMapper 22: private Map msgPKToOID; //msgPK -> OID 23: 24: public EIdentityMap() { decision let's find it control flow 25: OIDToObj = new HashMap(); 28: msgPKToOID = new HashMap();

29: } find it by OID where is it? retrieve it from the database 30: [ in cache ] [ not in cache ] 31: /** Get the stored contact */ 32: public IAContact findContact(int contactOID) { 33: return (IAContact) OIDToObj.get(new Integer(contactOID)); check if clean [ dirty ] 34: } entity package : EIdentityMap 35: /** Store a contact with the OID indicated */ 36: public void registerContact(IEObjectID oidObject) { foundation package : FReader 37: OIDToObj.put(new Integer(oidObject.getOID()), oidObject); is it clean? 41: } Data [ clean ] 42: /** Unregister a registered contact */ 43: public void unregisterContact(IEObjectID oidContact) { Mapper 44: OIDToObj.remove(new Integer(oidContact.getOID())); get it from the entity package : 46: } cache EContact © 113:Addison -Wesley} CAiSE 2003 Tutorial 51 © Addison-Wesley pattern CAiSE 2003 Tutorial 52

MModerator : MModerator : : FReader : EIdentityMap MDataMapper Load – Data MModerator() Load – Data MModerator() login() 1. retrieveEmployeeByName(username : String) logout() Check- Mapper updateMessage() 1.1. query(sql : String) retrieveUnsentMessages() out inin EMEM 1.2. createEmployee( ) -mapper

MDataMapper FReader 1.2.1. EEmployee(ref: IEDataSupplier) : EEmployee EIdentityMap MDataMapper() FReader() retrieveMessages() setConnection() EIdentityMap() retrieveMessageByOID() -reader query() 1.3. closeResult(rs : java.sql.ResultSet) findContact() retrieveMessageByID() closeResult() registerContact() storeMessage() unregisterContact() retrieveEmployeeByName() findEmployee() retrieveEmployeeByOID() 1.4. registerEmployee(oidObject : domain.entity.IEObjectID) registerEmployee() -cache retrieveEmployeeByID() unregisterEmployee() retrieveContactByOID() -writer FWriter findMessage() retrieveContactByID() getUnsentMessage() reretrieveMessage() FWriter() getUnsentMessages() doRetrieveMessages() setConnection() msgSize() createEmployee() update() registerMessage() createOutMessage() closeStatement() unregisterMessage() createContact() isMessageInCache() getEmployeeOID() getContactOID() getMessageOID() © Addison-Wesley CAiSE 2003 Tutorial 53 © Addison-Wesley CAiSE 2003 Tutorial 54

: CMsgSender : MModerator : : FWriter : EIdentityMap MDataMapper Lazy Load pattern

1. send(from : String, to : String, subject : String, body : String) Two kinds of retrieval operations: 2. updateMessage(msg : acquaintance.IAOutMessage) Unload – • Identity load 2.1. storeMessage(msg : acquaintance.IAOutMessage) Check-inin • Predicate load 2.1.1. update(sql : String) Three loading strategies: • Closure load 2.1.2. unregisterMessage(oidMessage : domain.entity.IEObjectID) • Flat load 2.1.2.1. flagCache(flag : boolean) • N-levels load Three approaches to Lazy Load: • Lazy Initialization • Virtual Proxy • OID Proxy

MDataMapper { Lazy Initialization return outmsg.getContact(); retrieveContactForOutmessage(outmsgID) } retrieveContact(contactID)

EOutMessage Method getContact()in EOutMessage <> outmsgID : String IAContact <> contactID : String Virtual public IAContact getContact() { contact : IAContact getContactID() if (contactOID == null) getFirstName() getContact() getFamilyName() Proxy contact = MDataMapper.retrieveContact(contactID); return contact; { return contact; } } EContactProxy EContact realSubject : IAContact n contactID : String contactID : String firstName : String familyName : String getRealSubject()

{ public String getFirstName() if (realSubject == null) { realSubject = MDataMapper.retrieveContact(contactID); return getRealSubject().getFirstName(); return realSubject; } }

OID Proxy : : : : EContact : A client object MDataMapper EOutMessage EContactProxy Internal programming mechanisms of ensuring the identity of 1. retrieveContactForOutmessage(outmsgID) objects loaded to memory 1.1. getContact( ) These are no replacement for OIDs assigned explicitly by the If EContact not loaded, retrieve 1.2. getFirstName( ) program it from the database and 1.2.1. getRealSubject( ) instantiate A singleton class that maintains maps of OIDs to objects can 1.2.1.1. retrieveContact(contactID) replace proxy classes: 1.2.1.2. getFirstName( ) EContactProxy knows PK of its • It knows if an entity object is loaded real subject • Upon loading, the object is given OID and all its data members 1.3. getFamilyName( ) are initialized (including FK values)

1.3.1. getRealSubject( ) • OID-based association links are initialized to null if the linked object has not been loaded yet. Virtual 1.3.1.1. getFamilyName( ) Dirty/clean status of an entity object: Proxy - • When first loaded, the entity object is flagged clean • If its data content gets out of sync with database, it is flagged dirty interactioninteraction • The entity object knows its clean/dirty status at all times

Navigation in Identity Map : : EIdentityMap : : EContact : A client object MDataMapper EOutMessage EIdentityMap 1. retrieveContactForOutmessage(outmsgID) MDataMapper OIDToObj : Map Checks if dirty OIDs : List msgPKToOID : Map (assuming 1.1. findOutmessage(outmsgOID) clean) Retrieves EContact by 1.1.1. isDirty( ) retrieveContactForOutmessage(outmsgID) findOutmessage(outmsgOID) contactID (FK in EOutMessage) retrieveContact(contactID) findContact(contactOID) and loads it. registerContact(OID) 1.1.2. getContact( ) 1.1.3. retrieveContact(contactID)

1.1.3.1. registerContact(OID) Checks if contactID EOutMessage (FK) is null (assuming EContact 1.1.3.1.1. setContactOID(OID) it is not). Then checks OID : int Navigation if contactOID is null OID : int <> outmsgID : String (assuming it is). dirty : boolean contactOID : int A client object <> contactID : String inin IdentityIdentity has EContact, so it can get its getContactOID() dirty : boolean data.

getContactID() 2. getFirstName( ) getFirstName() getContact() Map - getFamilyName() getContactOID() 3. getFamilyName( ) isDirty() setContactOID(OID) interactioninteraction setDirty(Flag) isDirty() setDirty(flag)

Presentation -menu Presentation IPScreen : : EIdentityMap : : EContact : A client object MDataMapper EOutMessage PMain display() 1. retrieveContactForOutmessage(outmsgID) Checks if dirty and control and control (from presentation) (assumi ng clean) 1.1. isDirty( ) Checks if contactID -menu (FK) is null (assuming it is not). Then checks in EM 1.2. getContact( ) in EM <> if contactOID is null (assuming it is). 1.2.1. retrieveContact(contactID, outmsgOID) POutMsgListViewer -listViewer PMenu -msgBuilder POutMsgBodyBuilder Retrieves (from presentation) (from presentation) (from presentation) 1.2.1.1. registerContact(contactOID, outmsgOID) EContact by contactID (FK in EOutMessage) 1.2.1.1.1. setContactOID(contactOID) and loads it.

1.2.1.1.2. setContact(contact) Navigation -admin -msgSeeker -msgSender If a client object did not request the whole object , but specific -msgSeeker inin EntityEntity EContact's data, then messages CMsgSeeker CAdmin CMsgSender like getFirstName() would originate from EOutMessage (from control ) (from control ) (from control ) -msgSeeker -msgSender Classes - 2. getFirstName( ) 3. getFamilyName( ) -moderator interaction -moderator -moderator interaction MModerator (from m edi ator)

MModerator i n sta n tia te s implements OID (from m edi ator) entity objects Proxy and supports and generates navigation in OIDs identity map -mapper IAConstants Mediator and (from acquaintance) Domain MDataMapper -cache EIdentityMap foundation in EM -OIDs contains all entity -OIDToObj -msgPKToOID in EM objects in EM List Map

MModerator -mapper MDataMapper IEObjectID EEmployee (from entity) (from m edi ator) (from m edi ator)

setOID(oid : int) : void associations between getOID() : int entity objects provide support for OID Proxy and navigation in entity classes

-msgs

EContact -msgs -reader -writer IAOutMessage -connection

FReader -reader FConnection FWriter (from foundation) (from foundation) (from foundati on) -sender -writer -contact EOutMessage -creator IAEmployee IAContact (from acquaintance)

CCD UF

DEFINITION: Cumulative Class Dependency (CCD) is the total supportability cost DEFINITION: Unsupportability Factor (UF) is the result of the division of the CCD for over all classes Ci{i=1,…,n) in a system of the number of classes Cj(j<=1,…,n) to be an unsupportable system by the CCD for a corresponding supportable system, i.e. the potentially changed in order to modify each class Ci. system that conforms to supportable architectural framework, such as PCMEF.

Consider the PCMEF design with five classes and that the Calculation of CCD assumies adherence to the CCD for it is also 5. architectural framework. For a corresponding unsupportable system, the CCD would If the framework is found to be broken, the CCD is be 20: calculated as if a class can depend on any other class in the system. 5! 120 • probability theory method - the combinations counting rule 5 CCD2 = × 2 = × 2 = 20 • The CCD is the number of different combinations of pairs of 2!(5 − 2)! 12 dependent classes which can be formed from the total number The UF is therefore 20/5 = 4. of classes in the design multiplied by 2 (cycles) The UF factor serves as a modifier of the more detailed n! CCD = × 2 metrics computed for designs/systems that were found to be n 2 2!(n − 2)! unsupportable.

CMD CMD – calculation example

Consider a class C that contains two methods m1 and m2. DEFINITION: Cumulative Message Dependency (CMD) is the total supportability Consider further that m1 calls m2 (as the only thing that it cost over all Synchronous Messages SM within client objects of the costs associated with i does). changes to methods Mj in supplier objects or responsible delegator objects that are accountable for servicing SMi. When calculating CMD, the dependency value for offending (unsupportable) If m2 is an empty method, then MDC for class C is equal 1 messages is increased by the Unsupportability Factor (UF). (because m1 depends on m2). If, however, m2 contained calls (messages) to two other If a responsible delegator object delegates the work methods m3 and m4 in supplier objects within the same to an object in another package then the cost of package, then MDC for class C would be equal 3 (because inter-package dependency is carried by the m1 depends on m2, and m2 depends on m3 and m4). responsible delegator. If supplier objects in a neighborhood package serviced m3 and m4, then MDC for class C would be 5. Further delegation sequence does not result in an additional cost (i.e. non-responsible delegators do If supplier objects in a non-neighborhood package (according to the PCMEF framework) serviced m3 and m4, then MDC for not carry a maintainability cost). class C would further increase by the UF value.

public class CActioner { // client of EEmployee EEmployee emp; public void do1() { // MD = 2 CMD - supportable emp.do3(); } MDP = 0 MDC = 0 } MDP = 1 public class EEmailMessage { // client of EEmployee EEmployee emp; Entity public void do2() { // MD = 1 MDC = 1 EEmailMessage emp.do3(); } Mediator do2() } MBroker public class EEmployee { // responsible delegator MBroker brk; do3() public void do3() { // MD = 0 MDC = 0 EEmployee brk.do3(); } do3() } Foundation public class MBroker { // delegator MDP = 2 FUpdater upd; Control FUpdater public void do3() { // MD = 0 upd.do3(); do3() } CActioner MDC = 2 } do1() This is supportable model: public class FUpdater { // supplier CCD = 4 public void do3() { // MD is null CMD = 3 // code for do3 } © Addison-Wesley CAiSE 2003 Tutorial 71 } © Addison-Wesley CAiSE 2003 Tutorial 72

public class CActioner { // client of FUpdater CMD - unsupportable FUpdater upd; public void do1() { // MD = 2 MDP = 2 MDC = 2 upd.do3(); MDP = 1 } } public class EEmailMessage { // client of EEmployee EEmployee emp; Entity Control public void do2() { // MD = 1 CActioner emp.do3(); MDC = 1 EEmailMessage } do1() } do2() public class EEmployee { // responsible delegator FUpdater upd; public void do3() { // MD = 0 EEmployee MDC = 0 upd.do3(); Foundation do3() } } FUpdater public class FUpdater { // supplier This is unsupportable model: public void do3() { // MD is null CCD = 12 do3() // code for do3 UF = 3 } CMD = 1+(2*3) = 7 }

Event dependency = interface Event dependencies: implementation dependency do2() --> fireDecisionEvent() CED --> processDecisionEvent() EDP = 2 EDP = 4 (interface uses dependency)

DEFINITION: Cumulative Event Dependency (CED) is the total supportability cost Presentation Control CActioner over all methods containing “fire event” messages FEi plus over all methods containing processDisplayEvent() “process event” messages within publisher objects plus over all methods servicing these PDisplayEventSubscriber addDecisionEventListener() PEi removeDecisionEventListener() processDisplayEvent() fireDecisionEvent() “process events” SEi within subscriber objects. The PEi supportability cost is associated with n do2() changes to signatures of SEi methods. The SEi supportability cost is associated with PDisplayEvent CDecisionEvent changes to messages in the bodies of PEi methods. Messages within registrator objects as well PConsole n messages contained in bodies of SEi methods are excluded as they are computed as part of addDisplayEventListener() removeD isplayEventListener() CDecisionEventSubscriber the CMD calculation. When calculating CED, the dependency value for offending fireD isplayEvent() do1() (unsupportable) events is increased by the Unsupportability Factor (UF). processDecisionEvent()

Event dependencies: do1() --> fireDisplayEvent() Mediator --> processDisplayEvent() EDP = 2 (interface uses dependency) MSynchronizer

Event dependency = processDecisionEvent() interface implementation dependency

CCD:13 CMD:17 DQ tool CED:0 Pictorial summary

PCMEF application packages MModerator control mediator (from medi ator)

-moderator -moderator Programmable client presentation entity foundation CCD:13 Browser client CMD:9 CMsgSender CED:0 (from control )

-msgSender

CCD:15 CMD:15 Database CCD:75 CAdmin CED:0 Applet (from control ) CMD:32 CED:74 Application client -admin -admin Servlet Business components JSP Web Server PSendPreview PWindow Application (from presentation) CCD:31 (from presentation) EJB bean CMD:22 Server BC4J object CED:18

Additional references

FOWLER, M. (1999): Refactoring. Improving the Design of Existing Code, Addison-Wesley, 431p.

FOWLER, M. (2003): Patterns of Enterprise Application Architecture, Addison-Wesley, 531p.

GAMMA, E. HELM, R. JOHNSON, R. and VLISSIDES, J. (1995): Design Patterns. Elements of Reusable Object- Oriented Software, Addison-Wesley, 395p.

LARMAN, C. (2002): Applying UML and Patterns. An Introduction to Object-Oriented Analysis and Design and the Unified Process, 2nd ed., Prentice-Hall, 627p.

MARTIN, R.C. (2003): Agile Software Development, Principles, Patterns, and Practices, Prentice-Hall, 529p.