Avancier Methods (AM) Software Architecture Modularity and OO presumptions

Transcription

1 Methods (AM) Software Architecture Modularity and OO presumptions It is illegal to copy, share or show this document (or other document published at without the written permission of the copyright holder Copyright

2 Radically changing gear! Earlier discussion of business architecture This discussion of software architecture Enterprise 10 Business Function Business Function 100 Narrow Business Function Narrow Business Function 1,000 App App 10,000 Deployable Artifact Deployable Artifact Some modular design principles are relevant to both 100,000 Package / Name Space Package / Name Space 1,000,000 Class/Object Class/Object 10,000,000 Operation Operation Copyright

3 Software architecture as the finest-grained enterprise architecture EA regards the enterprise as a system, or a system of systems. Business architecture is highest level business system design Software architecture is lowest level business system design, including the decomposition of an application into components.net Application Assembly Module Name Space Class Operation Java Application JAR Package / Name Space Class Operation Copyright

4 Modular system design Divides the system into components - to perform the required processes Monolithic system Modular system Operation Operation Operation Operation Operation Operation Operation Operation Operation Operation Operation Operation Copyright

5 Modular design questions For 40 years, software gurus have continually revisited modular design and integration questions. How best to scope each module? avoid duplication between modules? separate modules? integrate modules? What principles might help? Copyright

6 Architecture principles promoted in a global organisation 1. Separate concerns (for flexibility and maintainability) 2. Build for competitive advantage / Buy for competitive parity 3. Encapsulate components (for CBD and SOA) 4. Use open APIs for inter-component communication 5. Loosely couple components (for flexibility and availability) 6. Use Event-Driven Architecture for broadcast updates 7. Maintain a single source of truth 8. Design for response time / latency 9. Design for graceful failure informing users 10. Web first: design for browser and client device independence Copyright Limited

7 Encapsulation Encapsulation Modularisation in the 1970s Remote Procedure Call The OOP revolution The MVC pattern Deliberate repetition of core concepts from day 1 Copyright

8 Encapsulate components ( a building block has a defined boundary ) The enclosure within a component of processes, meaning that the inner workings are invisible to outsiders. The enclosure within a component of data, so the only way to access that data is by using the interface of the component. API API Component Operation Operation Operation Operation Operation Get data Component State Data Operation Copyright

9 Use open APIs for inter-component communication To encapsulate means hiding the internal data and procedures of a system (component or object) behind its interface. The interface is a collection of accessible services. API API specification Operation: Get Address Get Address Address Server Component Operation: Put Address Put Address State Data Copyright

10 /Operation signature Define an operation s signature Name (Input Parameters): Output Reply API Signature API specification Operation: Get Address (Post Code, House Num): Address Operation: Put Address (Address, Post Code): OK or Fail Clients can make it work using only the signature Copyright

11 /Operation semantics or rules Designers have to understand, and ideally document, the rules governing an operation. Semantics Or Rules API specification Operation: Put Address (Address, Post Code): OK or Fail Precondition: Valid Post Code is entered Post condition: Address is added to the Post Code If the preconditions are true, and the operation proceeds to completion, then the post conditions will be true. Copyright

12 Test-driven design using preconditions and post conditions Some programming languages come with tools for specifying preconditions and post conditions, and testing them API API specification Operation: Get Address (Post Code, House Num): Address Precondition: Valid Post Code and House Num are entered Post condition: Correct Address is returned Operation: Put Address (Address, Post Code): OK or Fail Precondition: Valid Post Code is entered Post condition: Address is added to the Post Code Copyright

13 Don t forge the numbers - and NFRs! Some NFRs apply to a whole component But also, each service/operation has its own characteristics API Do you think the two services/operations share these measures? API specification Operation: Get Address (Post Code, House Num): Address Precondition: Valid Post Code and House Name are entered Post condition: Correct Address is returned Operation: Put Address (Address, Post Code): OK or Fail Precondition: Valid Post Code is entered Post condition: Address is recorded against the Post Code Non-functional characteristics Response time = < 3 seconds Throughput = 10 per second Copyright

14 Realisation (software sense) Realisation = providing implementations for services in an interface. Representable in ArchiMate as below Interface Interface Realised by Realised by Component Component Copyright

15 Separation of component, interface and service One component may realise more than one interface. older and newer versions, or full and restricted list of services. R One service can appear in several interfaces. E.g. 1 component 2 interfaces 4 services (one duplicated) CRUD Software Component Required behaviour Interface Physical Structure Software Operation API Software Component Copyright

16 Modularisation in the 1970s Encapsulation Modularisation in the 1970s Remote Procedure Call The OOP revolution The MVC pattern Copyright

17 1970s Mainframe modular design as in COBOL A COBOL program can delegate work to a reusable component A main program can perform an internal subroutine not encapsulated, since program and subroutine can access the same state data Several programs can call a properly encapsulated external module Computer Memory Main program PERFORM Sub routine CALL Module Both perform and call are local procedure calls, little more than a GO TO and a GO BACK in the memory space of a computer Another Main program CALL Copyright

18 1972 Criteria to Be Used in Decomposing Systems into Modules Parnas introduced the idea of information hiding. API One begins with a list of difficult design decisions. Each module is designed to hide a decision from the others. [e.g. hide] a data structure, its internal links, accessing procedures and modifying procedures. Get data State Data Component Copyright

19 1975 Jackson s modular design patterns Jackson taught us to resolve structure clashes by designing distinct modules to handle I/O data structures complex data types database structures Transaction File File reading module Mainframe software Report File Report writing module Date calculator module Data Access Modules Data Storage Hardware Copyright

20 1979 Three-layer software design pattern Define the I/O data structures Transaction File Report File Mainframe software Define the events and enquiries contained in the input data Define the persistent data structure Event & Enquiry Catalogue I/O modules LPC Event/Enquiry Control Modules LPC Structure the code into layers, so each layer offers services to the layer above. Data Access Modules Data Storage Hardware Copyright

21 Reuse of modules There were many attempts to create a shared module library Enabling programmers to copy a module into their own program Main program Module Library Module Module Success was patchy Around1975, Michael A Jackson reputedly said A module library is the only kind of library that everybody wants to put something in, and nobody wants to take something out of. Copyright

22 Remote Procedure Call Encapsulation Modularisation in the 1970s Remote Procedure Call The OOP revolution The MVC pattern Copyright

23 1980s: Client-server design The next trend was to physically separate code on end-user client devices from code on database servers. Client Device Network Server Device Copyright

24 When businesses gave client devices to their employees: Enterprise applications had to be divided between modules handling user interface data structures (on client devices) handling business data structures (on database servers). Mainframe External Interface I/O modules Rewrite User Interface Client Device Local call Remote procedure call Network Local call Event/Enquiry Controllers Data Access or Entity Maintenance Redeploy (with luck) Event/Enquiry Controllers Data Access or Entity Maintenance Server Device Copyright

25 Remember LPC versus RPC Local Procedure Call Simple Fast Available Secure Remote Procedure Call More complex Slower Less available Less secure Copyright

26 LPC versus RPC Local Procedure Call 1. The client makes a local procedure call to the server. 2. The server does what is requested 3. The server replies to the client Remote Procedure Call 1. The client makes a local procedure call to the client stub (parameters pushed on to the stack) 2. The client stub packs (marshalls) the parameters into a message and makes an OS call 3. The client's local OS sends the message from to the server s machine 4. The server s local OS passes the incoming packets to the server stub 5. The server stub unpacks (unmarshalls) the parameters from the message 6. The server stub calls the server procedure. 7. The server does what is requested 8. The server replies to the server stub 9. The server stub packs (marshalls) the parameters from the message 10. The server s local OS passes the incoming packets to the server stub 11. The server's local OS sends the message from to the client machine 12. The client stub unpacks (unmarshalls) the parameters into a message 13. The client stub and replies to the client. Copyright

27 How physical distribution influences logical modularisation Local interfaces - fine-grained Get/set customer name Client Get/set address Get/set telephone number Server Object(s) To reduce network chatter, remote interfaces need to be coarse-grained Get/set customer details Server device Get/set customer name Client Remote Facade Get/set address Server Object(s) Get/set telephone number Copyright

28 The OOP revolution Encapsulation Modularisation in the 1970s Remote Procedure Call The OOP revolution The MVC pattern Copyright

29 Approaching 1990, OOP became fashionable OO programming is different in three ways 1. Many instances (objects) of a module type (class) So many objects can be deployed in parallel 2. A module instance has a unique object identifier So clients can locate an object, and remember it 3. Classes can be related in a class hierarchy So objects of one class can inherit and extend the operations of another more generic class Copyright

30 OO presumption c 1990 Criteria to Be Used in Decomposing Systems into Classes In the decade after Parnas and Jackson, OO guru Bertrand Meyer proposed classes should be abstract data types, which encapsulate a data structure define operations performable on that data structure. Petrol-driven Vehicle Vehicle ID Weight Passengers FuelCap MPG getweight (VID): Weight addpassenger (VID): void getmpg (VID): MPG calcrange (VID): Range Copyright

31 OO presumption c 1990 Class = module type A class is a template for creating objects; It may define data types maintained variables, fields, attributes Customer Number Address Current Debt Credit Status CRM Notes Customer changeaddress (CustomerNumber Address): Done closeorder (CustomerNumber OrderValue): Done getdetails (CustomerNumber): Procedure Procedure Procedure And an interface containing operations External (aka Method or Operation) Internal Procedure (aka Method Body) Copyright

32 OO presumption c 1990 Clients need object identifiers When instantiated in memory an object is an instance of a class; it has Identity unique object Id - used by programmers State unique data values Behaviour general operations Object Id changeaddress (CustomerNumber Address): Done closeorder (CustomerNumber OrderValue): Done Customer Oak Road, Town 0 Excellent Wife called Mary Procedure Procedure getdetails (CustomerNumber): Procedure You call it to do work Using an object/method pair E.g /closeOrder Copyright

33 OO presumption c 1990 One name space Client and server objects work in the same name space So they know and can use each other s class names object identifiers and operation or method names. Object Id Oak Road, Town 0 Maximum Wife Mary Customer changeaddress (CustomerNumber Address): Done closeorder (CustomerNumber OrderValue): Done getdetails (CustomerNumber): Procedure Procedure Procedure Copyright

34 OO presumption c 1990 Stateful objects/modules Stateful objects persist, and retain their state in memory The earliest OO programs handled a few small stateful objects. The case studies were real-time process control systems objects live forever graphical user interfaces - objects deleted when the UI is closed Copyright

35 OO presumption c 1990 The OO envangelist view Objects model real world entities. Objects (like real world entities) are stateful and persist. Databases are merely infrastructure devices and SQL is evil! App Server operation operation Customer Object XXX Oak Road, Town 0 Maximum Wife Mary Class Library Customer Object YYY Ash Road, Town 200 Minimum Rude on the phone operation operation Copyright

36 OO presumption c 1990 Applying the idea to enterprise-scale applications Pure [Distributed Object] implementations are anarchistic. Objects can appear anywhere at any time. No one knows how to get rid of them. Not good for apps w millions of run-time objects. (Client/server survival guide 3 rd edition 1999) App Server operation operation Customer Object XXX Oak Road, Town 0 Maximum Wife Mary operation operation Class Library Customer Object YYY Ash Road, Town 200 Minimum Rude on the phone So there was a need for garbage collection Objects with object identifiers that no other object remembers can be deleted Copyright

37 OO presumption c 1990 Reuse by inheritance Classes can be related in a class hierarchy Objects of a subclass inherit or extend the operations of a super class E.g. you can ask a bowler object to update batting average reply with the player s name Copyright

38 OO presumption c 1990 Intelligent domain objects Domain Objects cooperate to perform a transaction Command :Pupil :School (new) :School (old) pupiltransfer (PupilNum, NewSchoolNum): Error removepupil (OldSchoolNum) addpupil (NewSchoolNum): NoRoomError Copyright

39 OO presumption c 1990 Synchronous request-reply invocations The client sees the communication as synchronous Client objects invoke server objects using an object-method pair an object id and a method or operation name Hold a connection and wait for a reply Copyright

40 OO presumption c 1990 Blocking servers The server sees the communication as synchronous The server blocks all clients bar the current one Copyright

41 OO presumption c 1990 The OO envangelists ambition Turn the world into one big OO program (one name space) Intelligent domain objects can run on different machines And cooperate as though they run on the same machine. Does this mean client objects must remember the network addresses of remote server objects? To be continued Copyright

42 Summary of early OO design presumptions Feature Naming Early OO design presumptions Clients need object identifiers One name space Recent SOA design presumptions? Paradigm Time Location COBOL modules Java objects CORBA Stateful objects/modules Reuse by OO inheritance Intelligent domain objects Request-reply invocations Blocking servers Remember remote addresses Copyright Limited

43 The MVC pattern Encapsulation Modularisation in the 1970s Remote Procedure Call The OOP revolution The MVC pattern Copyright

44 The MVC pattern: as Martin Fowler introduces it Originally developed for desktop computing in the 1970s. The Model contains Objects representing things that appear on the screen, regardless of the visual format Copyright

45 Adapting the MVC pattern for enterprise applications Separates modules that handle client-side data structures from modules that handle server-side data structures Client device (screen state) receives an input request, may modify it, asks the Model to return or change its state. Controller View after the Model has done its work, organises the state of the Model in the form a client wants to see. Web /app server (session state) Model retrieves state data relevant to the request, can return or change the state of the Model, may hold session data relevant to a client-side form or process Data server (record state) DB Copyright

46 Adapting the MVC pattern for enterprise applications Graphic based on how Fowler represents MVC interactions Client Web/App Server Data HTTP request A Web Server A Controller Model Model Objects Obect A View HTTP response Copyright

47 Adapting the MVC pattern for enterprise applications There are many variations of the pattern Controller View Controller View Controller View Model Model Model Other MVC variants include hierarchical model view controller (HMVC), model view adapter (MVA) model view presenter (MVP), model view viewmodel (MVVM) Copyright

48 MVC in web frameworks (Wikipedia says) Web frameworks divide MVC differently between client and server tiers. Early web frameworks mostly put MVC components on the server. E.g. Ruby on Rails, Django, ASP.NET MVC and Express Client sends hyperlink requests or form input to the controller Client receives a complete and updated web page (or other doc) from the view. Other frameworks allow MVC components to execute partly on the client E.g. AngularJS, EmberJS, JavaScriptMVC and Backbone (also see Ajax). Copyright

49 Footnotes On inheritance and OO-relational mapping Copyright Limited

50 Base class a superclass to which designers can add subclasses that extend, inherit from or derive from the base class. Vehicle Vehicle ID Weight Passengers Petrol-driven Vehicle Vehicle ID Weight Passengers FuelCap MPG getweight (VID): Weight addpassenger (VID): void getweight (VID): Weight addpassenger (VID): void getmpg (VID): MPG calcrange (VID): Range Copyright

51 Abstract or virtual operation an operation for which the signature (name, inputs and outputs) is defined, but not the internal procedure needed to implement the operation. Vehicle Vehicle ID Weight Passengers Petrol-driven Vehicle Vehicle ID Weight Passengers FuelCap MPG getweight (VID): Weight addpassenger (VID): void getweight (VID): Weight addpassenger (VID): void getmpg (VID): MPG calcrange (VID): Range Copyright

52 Abstract or virtual class presents an interface containing nothing but abstract or virtual operations. Vehicle Vehicle ID Weight Passengers Petrol-driven Vehicle Vehicle ID Weight Passengers FuelCap MPG getweight (VID): Weight addpassenger (VID): void getweight (VID): Weight addpassenger (VID): void getmpg (VID): MPG calcrange (VID): Range Copyright