ECE750-Topic11: Component-Based Software Systems

Transcription

1 ECE750-Topic11: Component-Based Software Systems Architectural Styles in CBSE Ladan Tahvildari, PEng Associate Professor Software Technologies Applied Research (STAR) Group Dept. of Elect. & Comp. Eng. University of Waterloo

2 Architectural Styles: Definitions Architectural styles are recurring patterns. Established, shared understanding of common design forms is a mark of a mature engineering field. Architectural style is an abstraction of recurring composition and interaction characteristics of a set of architectures. Styles are key design idioms that enable exploitation of suitable structural and evolution patterns and facilitate component, connector, and process reuse. ECE750-Topic 11 2

3 Basic Properties of Styles A vocabulary of design elements Component and Connector types (pipes, filters, clients, servers) A set of configuration rules Constraints that determine allowed compositions of elements (a component may be connected to at most two other components) A semantic interpretation Compositions of design elements have well-defined meanings Explanation of what components are supposed to do in general Explanation of how connections are meant to work ECE750-Topic 11 3

4 Benefits of Styles Design reuse well-understood solutions applied to new problems Code reuse shared implementations of invariant aspects of a style Understandability of system organization a phrase such as client-server conveys a lot of information Interoperability supported by style standardization components can be independently developed with a particular style in mind Visualizations style-specific depictions matching engineers mental models ECE750-Topic 11 4

5 Some Architectural Styles Learning the following domain/platform-independent styles: Pipes and Filters 2-Tiered (Client/Server) N-Tiered Layered Blackboard Model View Controller (MVC) Pipes and filters were easy The rest require a deeper understanding of connections ECE750-Topic 11 5

6 From Abstractions to Implementations Abstract views (platform independent, Written in UML) Abstract system architecture Architectural Styles Pipes and Filters 2-Tiered N-Tiered Layered Blackboard Model View Controller Domain-specific Models (Platform specific, Written in UML with extra notation) Enterprise Middleware Architecture Safety Critical Architecture Embedded System Architecture Implementations OO: simple Java: EJB, JMS, JSP.NET: COM+, ASP CORBA C ECE750-Topic 11 6

7 Style 1: Pipes and Filters Components are filters transform input messages into output messages All components of a pipe and filter architecture use the same interface Input through provided interface Output through required interface Usually one provided (input) interface and one required (output) interface Connectors are pipes simple connections between filters provided and required interfaces Style invariants filters are independent a filter has no knowledge of up- and down-stream filters Each filter exposes a very simple interface: it receives messages on the inbound pipe, processes the message, and publishes the results to the outbound pipe. ECE750-Topic 11 7

8 Style 1: Pipes and Filters Advantages easy understanding of the system's behavior as the composition of filters filter addition, replacement, and reuse Disadvantages batch organization of processing interactive applications lowest common denominator on data transmission Commonly seen in UNIX shells Compilers Signal Processing Parallel Programming But also useful style for Enterprise Systems ECE750-Topic 11 8

9 Style 1: PF Example In many enterprise integration scenarios, a single event triggers a sequence of processing steps, each performing a specific function. Consider an order processing system -- new orders arrive from a client component in the form of a message. Requirement 1: the message is encrypted to prevent eavesdroppers from spying on a customer's order. Requirement 2: the messages contain authentication information in the form of a digital certificate to ensure that orders are placed only by trusted customers. ECE750-Topic 11 9

10 Style 1: PF Example Consider an order processing system -- new orders arrive from a client component in the form of a message. Requirement 3: duplicate messages could be sent from external parties (remember all the warnings on the popular shopping sites to click the 'Order Now' button only once?). To avoid duplicate shipments and unhappy customers, we need to eliminate duplicate messages before subsequent order processing steps are initiated. To meet these requirements, we need to transform a stream of possibly duplicated, encrypted messages containing extra authentication data into a stream of unique, simple plain-text order messages without the extraneous data fields. ECE750-Topic 11 10

11 Style 1: PF Example External client component produces an order message Messages are input/output using the same simple interface transmit(msg:object) is the method that transmits the message msg, typed as an Object <<Interface>> IMessage +transmit(msg:object) IMessage Decryption Deduplication Authentication Order processing system IMessage OrderSystem ECE750-Topic 11 11

12 Style 1: PF Example Pipes and filters lets us perform complex processing on a message while maintaining independence and flexibility Because all components use the same external interface they can be composed into different solutions by connecting the components to different pipes We can add new filters, omit existing ones or rearrange them into a new sequence -- all without having to change the filters themselves. Orders are no longer encrypted but we want a log of each message sent Better to authenticate orders before deduplicating Decryption Logbook Authentication Deduplication Authentication Deduplication OrderSystem ECE750-Topic 11 12

13 Style 2: 2-Tiered Client/Server One of the most common styles in distributed systems Components are clients and servers Constraints Application logic is divided between clients and servers two tiers E.g., client could handle presentation logic, while the server handles business rules and the database Clients and servers may be composite Server provides services to the client, but doesn t require Clients require services of the server A larger number of clients than servers Semantics (meaning and implementation) Servers do not know the number or identities of clients Clients know server s identity Clients and servers are often distributed Useful whenever there is a need to separate application logic into two tiers ECE750-Topic 11 13

14 Style 2: 2 Tiered Client/Server Example Google offers its search engine as a webservice A range of clients use SOAP to use the provided interface of the webservice A webpage servlet client uses the webservice as part of its webpages A.NET based b-2-c middleman application uses the webservice to search for best buys of products Different clients have very different purposes but the webservice server has the same functionality It makes sense to keep web searching and client functionality separate to both maximize on possible uses of the server and also to enable better maintenance Multiplicities of usage are written on the sides of connected interfaces In this example, the webservice can have many clients, so we put * on the clients required interfaces Webpage (client) * *.NET application (client) 1 Google webservice (server) ECE750-Topic 11 14

15 Style 3: N-Tiered Similar to client/server, but with a set of components, acting as both clients and servers: servers can also be clients of other servers Application logic is divided between the chain of components e.g., client could handle presentation logic, while one server handles business rules, connected to another server that handles the database Clients and servers may be composite Constraints Servers provides services to their clients, but doesn t require Clients require services of the server ECE750-Topic 11 15

16 Style 3: N-Tiered Semantics Servers do not know the number or identities of their clients Clients know server s identity Components are usually distributed Useful whenever there is a need to separate application logic into software packages ECE750-Topic 11 16

17 Example Typical 3 Tiered Architecture ClientSession CheckoutView ClientView CatalogueView Presentation Tier Spamazon <<delegate>> OnlineBookstore Checkout Purchasing Business Logic Tier BookCatalogue ElectronicCatalogue LoyaltyProgram <<delegate>> <<delegate>> DBConnectivity Data Tier ECE750-Topic 11 17

18 Style 3: N-Tiered Advantages Separation of concerns, divide and conquer approach to solving large scale software problem Maintenance Disadvantages Performance (especially if distributed components) ECE750-Topic 11 18

19 Style 4: Layered Architectures Hierarchical system organization multi-level client-server Components are classified by layers each layer exports an interface to be used by above layers Constraints Each layer acts as a 1-1 relation Each layer communicates only with its neighbors below it Connectors are protocols of layer interaction Examples Operating Systems Network Communications ECE750-Topic 11 19

20 Style 4: Layered Architectures Example HTTP Protocol Stack Each layer communicates to the next via an interface, taking information according to a certain network protocol ApplicationLayer IHTTP TransportLayer Application Layer Transport Layer HTTP Request TCP HTTP Request ITCP Network Layer IP TCP HTTP Request NetworkLayer IIP Data Link Layer Ethernet IP TCP HTTP Request DataLinkLayer IEthernet Physical Layer PhysicalLayer ECE750-Topic 11 20

21 Style 4: Layered Architectures Advantages increasing abstraction levels Maintainability each layer s role is defined Reuse Portability (replacing layers to work within a different context) Disadvantages not universally applicable some components may be spread around different layers Performance determining the correct abstraction level In practice layer bridging may be required a layer might need to communicate directly with a nonneighbour ECE750-Topic 11 21

22 Style 5: Blackboard (Repository) Two kinds of components Central data structure blackboard or repository Client components operate on and receive information from the blackboard System control is driven by the blackboard state Constraints One blackboard 1..n clients ECE750-Topic 11 22

23 A Closer Look at Connections In UML 2, connections are understood as an architectural abstraction of usage between components An abstraction of many possible implementations Recall our simple Java implementation of a connection: a reference to one component class A within another B In such an implementation, the class object implementing A communicates with the object for B by calling methods on the B s interface This kind of communication is synchronous: if A calls a method on B and then A must waits for the method to finish computing and return before A can continue A B ECE750-Topic 11 23

24 Synchronous Communication :A :B Computation Call to method Computation Method returns When we draw a connection in a UML 2 architecture, we could implement the connection as synchronous communication UML 2 is completely implementation independent, so there is no native way to specify that a connection should correspond to synchronous communication UML 2 lets us specify whatever constraints we want via stereotypes <<synchronous>> stereotype to denote that a connection should be implemented with synchronous semantics Computation ECE750-Topic 11 24

25 Asynchronous Communication A can continue its computation immediately after invoking a method on B Call from A does not require that B return immediately We use the <<asynchronous>> stereotype to specify that a connector has this form of implementation semantics ECE750-Topic 11 25

26 Publish/Subscribe Communication Components subscribe to events from a publisher component :B :A Subscribe :C The publisher sends events to all subscribing components The subscribers are anonymous to the publisher Computation Computation Notify Computation Computation Subscribe Notify Computation Computation The anonymity is ignored at the architectural level Our own <<publish/subscribe>> stereotype to designate this style of implementation semantics Notify Computation Computation Computation B <<publish/subscribe>> C A ECE750-Topic 11 26

27 Style 5: Blackboard Semantics Client components encapsulate individual pieces of application functionality Interaction between clients takes place only through the blackboard Clients make changes to the blackboard that lead incrementally to a desired outcome (e.g., solution to the application problem) In an implementation, the blackboard is active -- state of the blackboard is a trigger for selecting processes to execute Connections between components have a special semantics publish/subscribe Clients subscribe to information provided by the blackboard, registering the data they are interested in via required interfaces The blackboard may publish a notification to clients when data of interest changes through provided interfaces ECE750-Topic 11 27

28 Style 5: Blackboard Example 1 Examples Often used for AI systems Integrated software developments environments (e.g., Visual Studio, Borland Development Environment, Eclipse) Software development environment One stateful repository component deals with the maintenance of a software project s code Three stateless components present views on the code a change in one will change the code in the repository which will then result in parallel changes to the other views Changing the class hierarchy (e.g., making one class now inherit from another) results in a change to code in the repository and consequent updates to the UML visual class structure and the code view ClassHierarchyView UMLView RawCodeView CodeRepository <<publish-subscribe>> ECE750-Topic 11 28

29 Style 5: Blackboard Example 2 Holiday reservation system example: all reservations are ultimately stored on a database CarResView Three components deal with different aspects of holiday reservation logic AirResView HotelResView Each component could connect to the database separately especially as a change in one aspect (like date of air reservation) effects another aspect (like valid dates to book a hotel) Solution: use an intermediate single blackboard component to connect to the database dealing with all data of a user s reservation Three reservation logic components can change the blackboard Components can also subscribe to be notified of important changes to the blackboard data <<Publish/ Subscribe>> ReservationState DBConnectivity Dates of aeroplane ticket changed ReservationState updated ReservationState sends a notification if car reservation or hotel reservation dates do not lie within aeroplane dates ECE750-Topic 11 29

30 Style 5: Blackboard Advantages Clients are relatively independent of each other Data store is independent of clients Scalable (new clients can be added easily) Modifiable, maintainable Data integration can be achieved through the blackboard ECE750-Topic 11 30

31 Style 6: Model-View-Controller Three different kinds of components Model components are responsible for maintaining domain knowledge View components are responsible for displaying information to the user Controller components responsible for managing the sequence of interactions with the user. The model subsystems are designed such that they do not depend on any view or controller subsystems. Changes in their states are propagated to the view subsystems via a subscribe/notify protocol. ECE750-Topic 11 31

32 Style 6: Model-View-Controller Semantics: Model encapsulates application state exposes application functionality Notifies View of changes (often implemented as publish/subscribe) View Requests updates from models Senders user gestures to controller Allows controller to select view Controller Changes the state of the model Maps user actions to model updates (often implemented as publish/subscribe) Selects view for response ECE750-Topic 11 32

33 Heterogeneous Styles Combining different architectural styles Large architectures involving a combination of functionalities often entail a combination of styles in the best solution Challenge: Ensure advantages of individual style choices are not negated by their combination Good practice: Apply styles compositionally. Complex problems should be decomposed into subsystems apply single styles to independent subsystems (e.g., in a composite component) -- then we avoid style benefits being in conflict Safe practice: Mix styles if they work address orthogonal issues. For instance, n-tiered style is used structure an overall architecture, while blackboard style is used for a specific kind of problem solving ECE750-Topic 11 33

34 Example: 4 Tiered BB Architecture ReservationWebPageJSP Presentation Tier AirResServlet CarResServlet HotelResServlet Presentation Control tier <<Publish/ Subscribe>> ReservationState Bean Application Logic tier DBConnectivity Data tier ECE750-Topic 11 34

35 Architectural Models and Styles Architectural models are achieved in UML2 by: Component-and-connector diagrams, to define component relationships Interface descriptions, consisting of: method signatures (method names, input and output types) a semantics that tells us how methods work Architectural styles are defined in UML2 through: Explaining the kinds of components that are used in a style A semantics explaining how components and connections should behave Constraints telling us how the components are to be assembled ECE750-Topic 11 35

36 The Object Constraint Language (OCL) OCL is used for adding important information to UML models A business modelling language used within the Syntropy (Booch method) in IBM until it was added to UML in 1997 OCL is used To add constraints, restrictions on values that formed part of an object-oriented model To state conditions on execution of a system To define business rules To define queries on the model so questions about a model can be answered automatically by executing an OCL query OCL2.0 is a new improved version. ECE750-Topic 11 36

37 Building Better Models OCL is based on maths and first-order logic but is written like a programming language Example1: Consider the UML class diagram below The association between class Flight and class Person indicates that a certain group of persons are passengers on a flight -- the association is (0..*) on the side of the Person class The diagram says that the number of passengers is unlimited In reality, the number of passengers will be restricted to the number of seats on the airplane that is associated with the flight OCL can be use to specify such a constraint OCL CONSTRAINT: Inequalities for defining constraints OO dot notation for navigating around a model Context Flight Inv: passengers->size() <= plane.numberofseats ECE750-Topic 11 37

38 Expression Syntax OCL Types Custom: Defined by UML diagrams Predefined: Integer, Real, String and Boolean Collection Sets, ordered sets, and sequences Similar operations on sets as those on collections in Java (that is, we can define iterator expressions like foreach) OCL expressions are logical expressions about elements of OCL types Boolean propositions (true or false values) ECE750-Topic 11 38

39 Operations on Sets Operation s->size() s->intersection(t) s->union(t) s->count(o) s->includes(o) s->excludes(o) s->includesall(u) s->excludesall(u) s->isempty() s->notempty() Description Returns the number of elements in set s Returns the intersection of sets s and t Computers the union of s and t Number of times element o occurs in s True if o is an element of s True if o is not an element of s True if all elements of set u are in s True if all elements of set u are not in s True if s doesn t contain any elements True if s contains at least one element Examples - The followings are true OCL expressions about sets: Set{3,8,2,1}->size() = 4 Set{HotelRes,LoyaltyProgram}->excludes(CreditCardBill) Set{HotelRes,LoyaltyProgram}->union(Set{CreditCardBill}) = Set{HotelRes,LoyaltyProgram,CreditCardBill} ECE750-Topic 11 39

40 Iterators Are a powerful kind of OCL operation over collections used to perform operations repeatedly over each element of a collection of the form set->iterator(body) or set->iterator(variable body) each operation has an OCL expression as its parameter, called the body of the operation each operation also has an optional parameter, called an iterator variable used within the body Iterators are not new an important programming concept that is borrowed by OCL ECE750-Topic 11 40

41 Some Important Iterators Over Sets Operation s->any(expr) s->collect(expr) s->exists(expr) s->forall(expr) s->select(expr) s->reject(expr) Description expr is of the form variable body Returns a random element of set s for which expr is true Returns the set of objects that result from evaluating expr for each element in the source collection Returns true if there is at least one element in the source collection for which expr is true Returns true if expr is true for all elements in the source collection Returns a subset of s containing all elements for which expr is true Returns a subset of s containing all elements for which expr is false Example - The followings are true OCL expressions: Set{4,24,2000,2005}->select(x:Integer x=>2000) = Set{2000,2005} Set{4,24,2000,2002}->forAll(x:Integer x.mod(2) = 0) Set{4,24,2000,2005}->exists(x.Integer x.mod(2) = 1) ECE750-Topic 11 41

42 Context of OCL Expressions An OCL expression annotates a particular model entity (class, interface, datatype, component or entire application) this is called the context of the expression Annotation takes the following form: Context ModelEntity [init:/pre:/post: inv:] OCL expression about ModelEntity The context acts as a namespace for the OCL expressions The OCL expression can refer to aspects of the context: the attributes and methods of the class the provided interfaces of the component the required interfaces of the component ECE750-Topic 11 42

43 Types of Constraints An invariant is a constraint that states a condition that must always be met by all instances of the component, type, or interface. An invariant is described using an expression that evaluates to true if the invariant is met. Invariants must be true all the time. A precondition to an operation is a restriction that must be true at the moment that the operation is going to be executed. The obligations are specified by postconditions. A postcondition to an operation is a restriction that must be true at the moment that the operation has just ended its execution. ECE750-Topic 11 43

44 Example 2 Any human reader of the model will undoubtedly assume that a number of rules must apply to this model. A person may have a mortgage on a house only if that house is owned by himor herself; one cannot obtain a mortgage on the house of one's neighbor or friend. The start date for any mortgage must be before the end date. The social security number of all persons must be unique. A new mortgage will be allowed only when the person's income is sufficient. ECE750-Topic 11 44

45 Example 2 Augmenting Model with OCL Expressions context Mortgage inv: security.owner = borrower context Mortgage inv: startdate < enddate context Person inv: Person::allInstances()- >isunique(socsecnr) context Person::getMortgage(sum : Money, security : House) pre: self.mortgages.monthlypayment- >sum() <= self.salary * 0.30 context Person::getMortgage(sum : Money, security : House) pre: security.value >= security.mortgages.principal->sum() ECE750-Topic 11 45

46 Components as Substitutable Units Substitutability: Replace a component with an alternative or updated version without breaking the systems in which the component is used New system = old system with Hotel reservation component replaced Hotel reservation Hotel reservation 2 Holiday reservation session Air reservation Holiday reservation session Air reservation Car reservation Car reservation HolidayRes 3.0 HolidayRes 2005 ECE750-Topic 11 46

47 Laws of Substitutability A component B can be substituted for component A if, and only if, A s provided interfaces are preserved by B (that is, signature and expected behaviour preserved) B s required interfaces are the same as or fewer than A s (that is, B cannot require more) These constraints must be satisfied in order to avoid system breakage ECE750-Topic 11 47

48 Substitutability That definition was vague about expected behaviour being preserved. If the interfaces have OCL contracts, then we will define the formal laws of substitutability. Component B can be substituted for component A if, and only if, A s provided interfaces are preserved by B B s required interfaces are the same as or fewer than A s (that is, B cannot require more) Preconditions of B s provided interfaces are weaker than (are entailed by) preconditions of A s interfaces Postconditions of B s provided interfaces are stronger than (entail) postconditions of A ECE750-Topic 11 48

49 Substitutability Constraints HTTP WebServer WebServer:: Pre: ishttp1.0(msg) Post: ishtml(return) Can be replaced by HTTP WebServer2 WebServer2:: Pre: ishttp1.1(msg) Post: secure and ishtml(return) ishttp1.0 entails ishttp1.1 & secure and ishtml entail ishtml Webserver2 is substitutable for Webserver ECE750-Topic 11 49

50 Navigation Mechanism An OCL expression can navigate from its context element to associated elements using the dot notation, just as in Java Notation: To navigate over connections between components in architecture diagrams, we need to label the beginnings and ends of connections, giving names to the component instances referenced by the connections HolidaySys accesses CarRes component via ICarBooking interface, referring to component instance as mycarres mycarres myholidaysys CarRes ICarBooking HolidaySys IHotelBooking myholidaysys HotelRes myholidaysys If c.pinterfaces returns the set of all provided interfaces for a component, then Context HotelRes inv: myholidaysys.mycarres. pinterfaces->size() = 1 uses navigation to make a statement about CarRes relative to the HotelRes context ECE750-Topic 11 50

51 Assumed sets We assume the following sets are available for UML2 architectures: App.components provides the set of all components used within App c.provides gives the set of all the provided interfaces of a component c c.requries gives the set of all the required interfaces of a component c c.connections gives the set of all connected components to a component c Full OCL expressions can be defined to obtain these sets ECE750-Topic 11 51

52 Pre- and Post- conditions over Architectures Pre and post conditions can express important interaction across an architecture (not just local interaction with respect to interface implementations) Example: we can express that a call to HolidaySys s makeres(person, date) operation should result in calls to CarRes and HotelRes in the following way: Context: HolidaySys:: makeres(person,date) Post: self.mycarres^makeres (person,date) and self.myholidaysys^makeres (person,date) HolidaySys myholidaysys myholidaysys ICarBooking IHotelBooking mycarres myholidaysys CarRes HotelRes ECE750-Topic 11 52

53 Invariants over Architectures Invariants can be used to specify roles, relationships and dependencies that do not change over the execution of an architecture Example: assume c->down() means a component c is unavailable the invariant that the HolidaySys component is dependent on HotelRes and CarRes is defined as follows: Context HolidaySys Inv: self.mycarres->down() and self.myholiday->down() implies self->down() mycarres myholidaysys ICarBooking HolidaySys IHotelBooking myholidaysys myholidaysys CarRes HotelRes ECE750-Topic 11 53

54 Expressing Styles Formally When we discussed styles, we defined constraints over target architectures informally, using English. Example: Pipes-and-Filters has the constraint that every component used in the style provides and requires the same interface, and each component is connected to the other in a chain These constraints are usually very general, involving whole sets of components and connectors used in an architecture Using sets and set operations, it is possible to formalize these constraints ECE750-Topic 11 54

55 Pipes-and-Filters in OCL Let App be the part of an architecture that implements the style. Then: App.components->forall(c c.provides = c.requires and c.connections->size() > 0 and c.connections->size() < 3) and App.components->forall(c App.components->forall(d c.provides = d.requires)) Alternatively, expressed using context/invariant syntax: Context App Inv: self.components->forall(c c.provides = c.requires and c.connections->size() > 0 and c.connections->size() < 3) and self.components->forall(c self.components->forall(d c.provides = d.requires)) ECE750-Topic 11 55