Advanced Software Engineering (Software Engineering 2) Lecture Notes PDF

Faculty of Computers and Artificial Intelligence Master of Computer Science Advanced Software Engineering (Software Engineering 2) Dr. Lamia Abo Zaid ‫ لمياء أبوزيد‬. ‫د‬...

Faculty of Computers and Artificial Intelligence Master of Computer Science Advanced Software Engineering (Software Engineering 2) Dr. Lamia Abo Zaid ‫ لمياء أبوزيد‬. ‫د‬ Course Code: CS l.abozaid@fci -cu.edu.eg LECTURE 1: ADVANCED TOPICS IN SOFTWARE ENGINEERING Course Material ❑ Lecture Slides ❑ Selected papers from the literature ❑ Text books: ❑Other sources ❑Software Engineering Body of Knowledge SWBOK ❑Miscellaneous papers /online sources LECTURE 1: ADVANCED TOPICS IN SOFTWARE ENGINEERING Software Design And Architecture: TOC Introduction to the Architecture design process, and types of Architecture design. Software Architecture design process models. Architecture/Design representation Design Plans/architecture for common types of software systems Design strategies and methods Design assessment and validation LECTURE 5: ARCHITECTURE STYLES Architectural Styles ❑Certain design choices regularly result in solutions with superior properties ▪ Compared to other possible alternatives, solutions such as this are more elegant, effective, efficient, dependable, evolvable, scalable, and so on ❑Definition ▪ An architectural style is a named collection of architectural design decisions that □ are applicable in a given development context □ constrain architectural design decisions that are specific to a particular system within that context □ elicit beneficial qualities in each resulting system LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Basic Properties of Styles A vocabulary of design elements ◦ Component and connector types; data elements ◦ e.g., pipes, filters, objects, servers A set of configuration rules ◦ Topological constraints that determine allowed compositions of elements ◦ e.g., a component may be connected to at most two other components A semantic interpretation ◦ Compositions of design elements have well-defined meanings Possible analyses of systems built in a style LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Benefits of Using 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 Style-specific analyses ◦ Enabled by the constrained design space Visualizations ◦ Style-specific depictions matching engineers’ mental models LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Style Analysis Dimensions What is the design vocabulary? ◦ Component and connector types What are the allowable structural patterns? What is the underlying computational model? What are the essential invariants of the style? What are common examples of its use? What are the (dis)advantages of using the style? What are the style’s specializations? LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES The Launer Lander Game A simple computer game that first appeared in the 1960’s A player controls a spaceship as it falls towards the surface of the moon. The objective of the player is to land safely on the moon without running out of fuel, and without crashing (i.e., to land with small enough velocity so as not to crash). The lunar lander state has several fields: height, velocity, fuel, and moon gravity. LECTURE 5: ARCHITECTURE STYLES The Lunar Lander’s Workflow The user inputs a burn rate (i.e. rate at which the fuel is to be burned over the next time interval t) The system: Retrieves the current state (height, velocity, fuel, and gravity) of the lunar lander Calculates the new state (height, velocity, fuel) of the lunar lander after time t. Displays the new state on the screen to the user. Checks if the ship has landed. ◦ If yes, end the game. ◦ If no, go to step 1 (new burn rate) LECTURE 5: ARCHITECTURE STYLES Data-Flow Styles Batch Sequential ◦ Separate programs are executed in order; data is passed as an aggregate from one program to the next. ◦ Connectors: “The human hand” carrying tapes between the programs, a.k.a. “sneaker-net ” ◦ Data Elements: Explicit, aggregate elements passed from one component to the next upon completion of the producing program’s execution. Typical uses: Transaction processing in financial systems. “The Granddaddy of Styles” LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES  Batch-Sequential: A Financial Application LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Pipe and Filter Style Components are filters ◦ Transform input data streams into output data streams ◦ Possibly incremental production of output Connectors are pipes ◦ Conduits for data streams Style invariants ◦ Filters are independent (no shared state) ◦ Filter has no knowledge of up- or down-stream filters Examples ◦ UNIX shell signal processing ◦ Distributed systems parallel programming Example: ls invoices | grep -e August | sort LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Pipe and Filter (cont’d) Variations ◦ Pipelines — linear sequences of filters ◦ Bounded pipes — limited amount of data on a pipe ◦ Typed pipes — data strongly typed Advantages ◦ System behavior is a succession of component behaviors ◦ Filter addition, replacement, and reuse ◦ Possible to hook any two filters together ◦ Certain analyses ◦ Throughput, latency, deadlock ◦ Concurrent execution LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Pipe and Filter (cont’d) Disadvantages ◦ Batch organization of processing ◦ Interactive applications ◦ Lowest common denominator on data transmission LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Pipe and Filter – Example LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Client-Server LECTURE 4: INTRODUCTION TO THE ARCHITECTURE DESIGN - ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Layered Style Client Server Tired Model (n-tier) Each layer exposes an interface (API) to be used by the layer above it Each layer acts as a ◦ Server: service provider to layer “above” ◦ Client: service consumer of the layer “below” LECTURE 5: ARCHITECTURE STYLES Layered Style Components ◦ layers: composed of groups of sub tasks/systems ◦ API: set of classes exposing an API layer Connectors ◦ communication protocols/interfaces ◦ define the inter-layer interaction ◦ should facilitate loose coupling ◦ aim for standardized communication mechanism LECTURE 5: ARCHITECTURE STYLES Layered Style: Client-server Layered application example Client-server , 3- tier LECTURE 5: ARCHITECTURE STYLES Layered Style: Virtual Machines Virtual Machines When the layer interactions is not limited to adjacent layers only What are the advantages of Layered style ? LECTURE 5: ARCHITECTURE STYLES Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 5: ARCHITECTURE STYLES Blackboard Style Blackboard is useful for problems for which no deterministic solution strategies are known. In Blackboard several specialized subsystems (agents) assemble their knowledge to build a possibly partial or approximate solution. Blackboard allows multiple processes (or agents) to communicate by reading and writing requests and information to a global data store. Examples ◦ Typically used for AI systems ◦ Speech recognition ◦ Vehicle identification and tracking ◦ Identification of the structure of protein molecules ◦ Integrated software environments (e.g., Interlisp) LECTURE 5: ARCHITECTURE STYLES  Blackboard Style System control is driven by the blackboard state 1. Agents communicate strictly through a common blackboard whose contents is visible to all agents. 2. When a partial problem is to be solved, candidate agents that can possibly handle it are listed. 3. A control unit is responsible for selecting among the candidate agents to assign the task to one of them. 4. A control unit is responsible for selecting among the candidate agents to assign the task to one of them. LECTURE 5: ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Blackboard Style Two kinds of components ◦ Central data structure — blackboard ◦ Components operating on the blackboard ◦ agents also called knowledge source ◦ Control unit- driven by the blackboard state Connectors: depending on the context ◦ procedure calls, database queries, direct references LECTURE 5: ARCHITECTURE STYLES Blackboard Style Example LECTURE 5: ARCHITECTURE STYLES Rule-Based Style Inference engine parses user input and determines whether it is a fact/rule or a query. If it is a fact/rule, it adds this entry to the knowledge base. Otherwise, it queries the knowledge base for applicable rules and attempts to resolve the query. Examples: ◦ rule-based systems like expert systems ◦ Web scripting languages like JavaScript (client-side) or PHP (server-side) LECTURE 5: ARCHITECTURE STYLES Rule-Based Style Components: User interface, inference engine, knowledge base Connectors: Components are tightly interconnected, with direct procedure calls and/or shared memory. Data Elements: Facts and queries Behavior of the application can be very easily modified through addition or deletion of rules from the knowledge base. Caution: When a large number of rules are involved understanding the interactions between multiple rules affected by the same facts can become very difficult. LECTURE 5: ARCHITECTURE STYLES Rule Based Style Example: Lunar Lander game LECTURE 5: ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 5: ARCHITECTURE STYLES  Interpreter Style Interpreter parses and executes input commands, updating the state maintained by the interpreter Components: Command interpreter, program/interpreter state, user interface. Connectors: Typically very closely bound with direct procedure calls and shared state. Highly dynamic behavior possible, where the set of commands is dynamically modified. System architecture may remain constant while new capabilities are created based upon existing primitives. Supports dynamically changing set of capabilities Examples: graphical editors, Visual basic Interpreter, Lisp and Scheme LECTURE 5: ARCHITECTURE STYLES  Interpreter Style Example: Lunar Lander game Material from [Bass et al. 98], [Slides by Spiros Mancoridis] LECTURE 5: ARCHITECTURE STYLES Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. Mobile-Code Style Allows code to be sent to a remote host for interpretation. Usually suitable for Code on Demand ◦ Client has resources and processing power ◦ Server has code to be executed ◦ Client requests the code, obtains it and runs it locally Examples Java applets, activeX controls, Scripting languages (e.g. Javascript) Components: “Execution dock”, which handles receipt of code and state; code compiler/interpreter Connectors: Network protocols and elements for packaging code and data for transmission. Data Elements: Representations of code as data; program state; data LECTURE 5: ARCHITECTURE STYLES Mobile-Code Style Remote execution/evaluation ◦ client has code but does not have resources to execute it ◦ software resources (e.g., interpreter) ◦ hardware resources (e.g., processing power) Examples are: ◦ Grid and cloud computing LECTURE 5: ARCHITECTURE STYLES Mobile-Code Style Mobile agent ◦ initiator has code and some resources but not all ◦ can autonomously decide to migrate to a different node to obtain additional resources Connectors: ◦ Remote Method Invocation (RMI) ◦ Common Object Remote Broker Architecture (CORBA) Examples ◦ processing large amounts of distributed data ◦ dynamic behaviour / customization (e.g. adaptive systems) LECTURE 5: ARCHITECTURE STYLES Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 5: ARCHITECTURE STYLES Implicit Invocation Style Event announcement instead of method invocation ◦ “Listeners” register interest in and associate methods with events ◦ System invokes all registered methods implicitly Component interfaces are methods and events Two types of connectors ◦ Invocation is either explicit or implicit in response to events Style invariants ◦ “Announcers” are unaware of their events’ effects ◦ No assumption about processing in response to events LECTURE 5: ARCHITECTURE STYLES Publish-Subscribe Style Subscribers register/deregister to receive specific messages or specific content. Publishers broadcast messages to subscribers either synchronously or asynchronously. Components: publishers, subscribers Connectors: procedure calls/network protocols Data: subscriptions, notifications, published information LECTURE 5: ARCHITECTURE STYLES Publish-Subscribe Style Examples ◦ Social media “friending” ◦ GUI ◦ Multi-player network-based games ◦ Online data feed (news, weather, job posting,..etc ) In Publish-Subscribe the publisher is responsible for maintaining the list of subscribers LECTURE 5: ARCHITECTURE STYLES Event-Based Style Independent components asynchronously emit and receive events communicated over event buses Components: Independent, concurrent event generators and/or consumers Connectors: Event buses (at least one) Data Elements: Events – data sent over the event bus Components communicate with the event buses, not directly to each other. Component communication with the event bus is push or pull based. ◦ In pull delivery, subscriber component initiates requests to the Pub/Sub bus to retrieve messages ◦ In push subscription, the Pub/Sub bus sends each message to the subscriber components. LECTURE 5: ARCHITECTURE STYLES Event-Based Style Advantages: ◦ Highly scalable, easy to evolve, effective for highly distributed applications. ◦ Easy to evolve (just add another component) ◦ Heterogeneous Example (push) LECTURE 5: ARCHITECTURE STYLES Some Common Styles Traditional, language-influenced styles Interpreter ◦ Main program and subroutines ◦ Interpreter ◦ Object-oriented ◦ Mobile code Layered Implicit invocation ◦ Virtual machines ◦ Event-based ◦ Client-server ◦ Publish-subscribe Data-flow styles Peer-to-peer ◦ Batch sequential Shared memory ◦ Pipe and filter ◦ Blackboard ◦ Rule based LECTURE 5: ARCHITECTURE STYLES Peer-to-Peer Style State and behavior are distributed among peers which can act as either clients or servers. Peers: independent components, having their own state and control thread. Connectors: Network protocols, often custom. Data Elements: Network messages LECTURE 5: ARCHITECTURE STYLES Peer-to-Peer Style Advantages ◦ Supports decentralized computing with flow of control and resources distributed among peers. ◦ Highly robust in the face of failure of any given node. ◦ Scalable in terms of access to resources and computing power. LECTURE 5: ARCHITECTURE STYLES Questions ? LECTURE 5: ARCHITECTURE STYLES Readings Software Architecture: Foundations, Theory, and Practice ◦ Chapter 3, 4 LECTURE 6: ARCHITECTURE DESOGN Quiz 1 What is software Architecture ? How is it related to software design Name at least two of the factors influencing the definition of architecture LECTURE 5: ARCHITECTURE STYLES Questions ? LECTURE 1: ADVANCED TOPICS IN SOFTWARE ENGINEERING