Software Architectures

Lecture 8 27 Oct 2014 Roadmap of the course

 What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles, observed the achieved qualities  The ADD method  Evaluating an architecture  Documenting software architecture  Bass et al  Hofmeister et al  Generalization, reuse: ADLs, PLs, COTS  Today we wrap up: Patterns, DCI, Coordination, SAr Design patterns Definitions

 A pattern is a recurring solution to a standard problem, in a context.  Christopher Alexander, a professor of architecture…  Why would what a prof of architecture says be relevant to software?  “A pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”  Jim Coplien, a software engineer: “I like to relate this definition to dress patterns…”  What are dress patterns?  “... I could tell you how to make a dress by specifying the route of a scissors through a piece of cloth in terms of angles and lengths of cut. Or, I could give you a pattern. Reading the specification, you would have no idea what was being built or if you had built the right thing when you were finished. The pattern foreshadows the product: it is the rule for making the thing, but it is also, in many respects, the thing itself.” Patterns in engineering  How do other engineers find and use patterns?  Mature engineering disciplines have handbooks describing successful solutions to known problems  Automobile designers don't design cars from scratch using the laws of physics  Instead, they reuse standard designs with successful track records, learning from experience  Should software engineers make use of patterns? Why?  “Be sure that you make everything according to the pattern I have shown you here on the mountain.” Exodus 25:40.  Developing software from scratch is also expensive  Patterns support reuse of software architecture and design The “gang of four” (GoF)  Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides (Addison-Wesley, 1995)  Design Patterns book catalogs 23 different patterns as solutions to different classes of problems, in C++ & Smalltalk  The problems and solutions are broadly applicable, used by many people over many years  Patterns suggest opportunities for reuse in analysis, design and programming  GOF presents each pattern in a structured format Elements of Design Patterns

 Design patterns have 4 essential elements:  Pattern name: increases vocabulary of designers  Problem: intent, context, when to apply  Solution: UML-like structure, abstract code  Consequences: results and tradeoffs Design Patterns are NOT

 Data structures that can be encoded in classes and reused as is (i.e., linked lists, hash tables)  Complex domain-specific designs (for an entire application or subsystem)  If they are not familiar data structures or complex domain-specific subsystems, what are they?  They are:  “Descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”

Observer pattern

 Intent:  Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically  Used in Model-View-Controller framework  Model is problem domain  View is windowing system  Controller is mouse/keyboard control

Structure of Observer Pattern

Subject Observer

for all observers obs +notify() * +update() { 1 obs->update() +attach(in Observer) } +detach(in Observer)

ConcreteObserver ConcreteSubject -subjectSate * +update() +getState() 1

return subjectState observerState = subject->getState() Three Types of Patterns  Creational patterns:  Deal with initializing and configuring classes and objects  Structural patterns:  Concerned with how classes and objects are composed to form larger structures  Deal with decoupling interface and implementation of classes and objects  Behavioral patterns:  Deal with dynamic interactions among societies of classes and objects  How they distribute responsibility Creational Patterns

 Abstract Factory:  Factory for building related objects  Builder:  Factory for building complex objects incrementally  Factory Method:  Method in a derived class creates associates  Prototype:  Factory for cloning new instances from a prototype  Singleton:  Factory for a singular (sole) instance Structural patterns  Describe ways to assemble objects to realize new functionality  Added flexibility inherent in object composition due to ability to change composition at run-time  not possible with static class composition  Example: Proxy  Proxy: acts as convenient surrogate or placeholder for another object.  Remote Proxy: local representative for object in a different address space  Virtual Proxy: represent large object that should be loaded on demand  Protected Proxy: protect access to the original object Structural Patterns

 Adapter:  Translator adapts a server interface for a client  Bridge:  Abstraction for binding one of many implementations  Composite:  Structure for building recursive aggregations  Decorator:  Decorator extends an object transparently  Facade:  Simplifies the interface for a subsystem  Flyweight:  Many fine-grained objects shared efficiently.  Proxy:  One object approximates another Behavioral Patterns

 Chain of Responsibility:  Request delegated to the responsible service provider  Command:  Request or Action is first-class object, hence re-storable  Iterator:  Aggregate and access elements sequentially  Interpreter:  Language interpreter for a small grammar  Mediator:  Coordinates interactions between its associates  Memento:  Snapshot captures and restores object states privately

Behavioral Patterns (cont.)

 Observer:  Dependents update automatically when subject changes  State:  Object whose behavior depends on its state  Strategy:  Abstraction for selecting one of many algorithms  Template Method:  Algorithm with some steps supplied by a derived class  Visitor:  Operations applied to elements of a heterogeneous object structure The Singleton Pattern

 Context:  It is very common to find classes for which only one instance should exist (singleton)  Problem:  How do you ensure that it is never possible to create more than one instance of a singleton class?  Forces:  The use of a public constructor cannot guarantee that no more than one instance will be created.  The singleton instance must also be accessible to all classes that require it Singleton

 Solution: The Observer Pattern  Context:  When an association is created between two classes, the code for the classes becomes inseparable.  If you want to reuse one class, then you also have to reuse the other.  Problem:  How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?  Forces:  You want to maximize the flexibility of the system to the greatest extent possible Observer

 Solution: The Delegation Pattern

 Context:  You are designing a method in a class  You realize that another class has a method which provides the required service  Inheritance is not appropriate  E.g. because the isa rule does not apply  Problem:  How can you most effectively make use of a method that already exists in the other class?  Forces:  You want to minimize development cost by reusing methods Delegation

 Solution: Delegation

Example: More software patterns  Design patterns  idioms (low level, C++): Jim Coplien, Scott Meyers  I.e., when should you define a virtual destructor?  design (micro-architectures) [Gamma-GoF]  architectural (systems design): layers, reflection, broker  Reflection makes classes self-aware, their structure and behavior accessible for adaptation and change: Meta-level provides self-representation, base level defines the application logic  Java Enterprise Design Patterns (distributed transactions and databases)  E.g., ACID Transaction: Atomicity (restoring an object after a failed transaction), Consistency, Isolation, and Durability  Analysis patterns (recurring & reusable analysis models, from various domains, i.e., accounting, financial trading, health care)  Process patterns (software process & organization)

Orchestration, choreography, coordination

Process Abstractions Orchestration: A process is a partial order of actions under the control of a central conductor; akin to a workflow [Global; central] Choreography: A process is an exchange of messages among participants; akin to a conversation as described by WSCL and WSCI [Global; distributed] Collaboration: A process is a joint set of activities among business partners [Local; distributed] Workflow: narrower concept than process, which emphasizes control and data flows from a central perspective; original idea behind modern orchestration WS-Coordination WS-Coordination is the specification for a service whose job is to coordinate the activities of the Web services that are part of a business process A coordination service is an aggregation of three services:  Registration: for parties to register with the coordinator  Activation: to create an instance of a coordination context  Coordination protocol: to define the specific protocol to be followed WS-Coordination Service

CreateCoordinationContext Register

Activation Registration Service Service

Coordinator

Protocol X Protocol Protocol Protocol Y Service X Service Y WS-Coordination Service

WStravel CoordinatorT CoordinatorH WShotel

CreateCoordContext(ACIDTrans)

Activation Ct(A1,ACIDTrans,RSt) Service

ReserveRoom(Ct)

CreateCoordContext(Ct) Activation Service Ch(A1,Ct,RSh)

Registration Service Reg(2PC,PortH)

Register(2PC,PortPSh) Registration Service RegisterResponse(AddACK,PortPSt)

RegResponse(RemoveACK,PortPSh)

Protocol Protocol RoomConfirmation(2PC) Service Service 2PC Protocol

ReservationConfirmed Benefits of Design Patterns  Design patterns enable large-scale reuse of software architectures and also help document systems  Patterns explicitly capture expert knowledge and design tradeoffs and make it more widely available  Patterns help improve developer communication  Pattern names form a common vocabulary DCI: data, context, interaction And a link to patterns End User System Experience End User mental model

domain model use cases (what the system IS) (what the system DOES)

Runtime (objects and interactions)

Chasm

Compile time (classes, superclasses)

class model code

Programmer mental model Object-Orientation: networks of communicating objects

The essence of object orientation is the interchange of messages that takes place in the space between the objects True Object Orientation Objects as participants in receive commnication

receive

receive End User’s Mental Model What the system DOES

Customer Bank FromAccount ToAccount

transfer ( amount, fromAccount, toAccount)

transfer (...)

deposit (...) Object Models are understandable

End user mental model explains how the system works. End user mental model is an object model: Objects • Can store data • Can handle received messages • Can send messages to other objects Objects interact to to achieve a use case Objects are named by the role they play in the interaction Coplien, Bjørnvig: Lean Architecture Building Software as if people mattered No waste Get it right the first time! Be prepared for changes! Lean Principle: ”everybody, all together, from early on.” System architecture shall reflect the end user's mental model. Architecture has two parts: What the system IS: Its state What the system DOES: Its behavior Architecture a skeleton program Gamma, Helm, Johnson, Vlissides: Design Patterns An object-oriented program's run-time structure often bears little resemblance to its code structure. • The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. • The run-time structure consists of rapidly changing networks of communicating objects. It's clear that code won't reveal everything about how a system will work. [GOF p.22, 23] The Essence of Object Orientation

 a class reveals everything about how an instance will handle an incoming message and reveals nothing about its collaborator or why the message was sent.  an object by itself is not interesting  the essence of object orientation is that objects communicate to achieve a common goal  We need explicit code that clearly specifies the Contexts, i.e., the networks of communicating roles Object Class Hierarchy copy is Irrelevant for program Shape execution center area

F_Circle F_Polygon

Circle Polygon copy copy center center area area radius vertices radius vertices The Chasm between End User and Programmer End User mental model

domain model use cases (what the system IS) (what the system DOES)

Runtime (objects and interactions)

Chasm

Compile time (classes, superclasses)

class model code

Programmer mental model Use Case Context and Roles

Environment BankTransferContext

role role role Customer Bank FromAccount ToAccount

transfer ( amount, fromAccount, transfer (..) toAccount) deposit (..)

role methods Three Perspectives Data – Context - Interaction Compile time Data, Context, Interaction

Object model code

Data – What-The-System-IS Implementation of user’s domain model Dumb, dumb classes and superclasses without interaction code. Context – The Roles Participating in a Use Case Roles and role structure Select objects to play the roles. Inject role methods into selected objects (or their classes) Trigger Interaction.

Interaction – What-The-System-DOES Role Methods direct the execution of the Use Case End User domain model

Conceptual schema Programmer’s «realize» Mental Model Class attributes Data Perspective + local methods

«instantiate classes to object» data objects End User use cases

Programmer’s Environment Mental Model use case Context Context Perspective Role Role Role Bind roles to objects data objects Programmer’s Mental Model The Whole Story End User domain use cases model Conceptual Environment schema use case task realize Context Class attributes Role Role + local methods Inject role Role + role methods methods «instantiate classes to objects» «bind roles to objects» data objects interaction End User Mental Model = Code End User mental model

domain model use cases (what the system IS) (what the system DOES)

Runtime (objects play roles) context selects objects instantiate data classes to play roles to objects inject role methods Chasm Bridged! Compile time (Data, Context, Interaction)

Object model code

Programmer mental model DCI and patterns Lean architecture

 Uses DCI  Focuses on the end users  Parts:  Partitioning  Selecting a design style  Documentation  Rough framing of the code  Relationships in architecture  Documentation  …

Software architect role SArchitect: what does it take?  Technical aspects of designing SA put in the context of the organizational structure  Many interactions  Managers, system architects, SW developers, other SArchitects, marketing personnel, customers  Must understand, coordinate with, and listen to them, communicate the SA vision to them  SArchitect  Responsibility beyond currently designed product  Advocate for the organization investing in SA Roles of a SArchitect

1. Creating a vision 2. Key technical consultant 3. Decision maker 4. Coordinator 5. Implementer 6. Advocate Creating a vision

 Successful SArchitect is visionary  Must know in advance  What the system will look like when done  What will accomplish  How it fits the company’s technology and business

Creating a vision: application domain

 Knowing application domain and/or targeted product is a plus  If not, need to learn about  Business  Market characteristics  Capabilities of the company’s products  Competitors

Creating a vision: qualities/factors

 Need to understand global requirements and constraints of product  Generate global view of system  Reiterate  Project with new technology, targeting new markets, fast time-to-market  Care must be taken in crafting a healthy vision

Creating a vision: innovations

 Innovations in the field fuel creativity  Company’s technology  What’s new in marketplace  Product users  Application specialists  Technical marketing  Customers  Visit user site (see how system is used in practice) The vision influences the other roles  Initial architecture is sketched on a paper  Architect needs to communicate vision  As coach  Work with project manager and team during high- level design and product development  As coordinator, decision maker, and implementer  Control key interfaces of architectural design  Provide requirements and input about how SW fits overall product  Verify agreed system interfaces can be met Creating a vision: COTS and adjustments  SA sketch determines  What COTS components are needed  What other existing SW can be reused to implement parts of the system  Realizing vision  May require new technology, organization changes  Discovered defects and holes in vision should be corrected midcourse and communicated Key technical consultant  To project manager (PM)  Close working relationship  PM ultimate responsibility for project  SArchitect technical authority needed by PM  Small projects: PM=SArchitect  Larger projects  Control of interfaces essential  Team of architects  System design review board  Formal authority for maintaining integrity of SA Key technical consultant, 2

Topic Project manager SArchitect SW development Organize project; manage Organize team around design, resources, budgets, schedules manage dependencies

Requirements Negotiate with marketing Review, negotiate req

Personnel Hiring, salary, bonuses Interview candidates; technical capabilities of staff; motivate development team

Technology Introduce new tech at Recommend technology, SArchitect’s recommendation training, tools

Quality Ensure quality of product Track design quality

Metrics Measure productivity, size, Ensure design goals met quality Decision maker

 High-level design team  SAr + leaders of subsystems / technology experts / domain specialty areas  Leader makes early design decisions  Trade-off conflicting demands  Enough domain knowledge to analyze design trade offs  If not enough, rely on specialists Decisions

 In a timely manner to meet deadlines  Even if no team consensus  Even if not all needed info is present  Just-in-time decisions  Delay as long as possible but no longer  Advantage: flexible design, incorporates changes to requirements and factors easier  Making no decision: worst case! Perspective on decisions  Decisions depend on scheduling dependencies  Work forward from the resources and backward from the goals  Order decisions  Consider marketing priorities, project schedule, new technology impact  SAr responsible for global decisions  Delegate decisions to area experts  Design and implementation decisions to development team, coaching if needed Coach  SAr and PM put together SMALL high- level design team  Additional staff added as lower-level design and implementation introduced  SAr and PM assign team members to work pieces  SAr ensures people understand the design  SAr convinces people the design can be implemented  Dialog with each team member, teaching important design aspects  Listen to their feedback; tradeoff! Team members and the coach  Team needs to understand SA design well- enough to do detailed design of their subsystems  Have each sub-team design decomposition of their subsystem and its interfaces to rest of system  Have them estimate time and complexity of implementation => feedback to schedule  This increases team’s feeling of ownership in SA design and development schedule Team members and the coach, 2

 SAr needs to  Do the overall structure of design  Give team members responsibility and challenge for designing their piece of system  SAr duties end when achieving appropriate level of detail  Allow team members small mistakes  Make sure they learn from them Coordinator  SA: unifying for product development  PM may view SA as vehicle for decomposing complex effort into manageable tasks  Technical marketing may use SA as to support new features over lifespan of product  SW engineers may be concerned with performance, reusability, evolution  SAr: keeper of SA  Coordinates activities of all these people SAr as coordinator  Establishes and controls key interfaces  Keep track of SW process  Makes sure important milestones met  Design reviews ensure consistency and quality of SA and that teams understands the design  Establishes team leader responsibilities  Together with PM  Team leaders should relate to each other; SAr ensures they coordinate  Maintains integrity of design, ensures architecture is followed  If not, rationale documented (special cases!) Implementer SAr plays role in implementing system  SAr needs to keep programming skills fresh  Track technologies and standards High-risk parts of system (exp: unknown)  SAr may step in and go into more detail  Exp: design initial base classes, code initial implementation SAr may implement a vertical slice of system to minimize implementation risk  Prototyping important  Understand design tradeoff  Predicting system performance  Educating the team on how to begin implementation Advocate for SA  Perhaps most important role  SA critical asset of the organization  SAr should keep track of existing SAs in the organization  To mine them for new SAs  To combine them into a product line  Does this investment make sense?  SAr should look beyond product boundaries  Reuse opportunies  SAr must asses and advocate SA technologies  New ones too SA into the development process

 SAr should work to incorporate SA in the development process => SA design activities become part of the standard operating procedure of organization SAr role  Project usually have official SAr  Must be position of authority  This understood by PM and rest of team  Otherwise  When crises appear, SAr can be reduced to solve them with no time for the real job  Without watchful SAr  SA begins to drift from intended design  SA more difficult to manage  SA vision begins to disappear SAr career  Steps  SW engineer  Senior SW engineer  Team leader  Apprenticeship with experienced architect  SAr  In this way, technical skills are developed first, then  Leadership, communication, people skills SAr vision again

 SAr needs to have  A vision of the product to be developed  Determination to strive to achieve the vision  Conviction and communication goals to influence entire team into believing that the vision can be achieved Instead of conclusions

 Course gives pointers  What is software architecture?  Designing Software Architecture  Requirements: quality attributes or qualities  How to achieve requirements : tactics  How do tactics lead to architectural styles  Case studies on architectural styles  The ADD method  Evaluating an architecture  Documenting software architecture  Bass et al  Hofmeister et al  ADLs  PLs, COTS, SAr  SA is about complexity, organization, details  SAr ensures quality attributes will be respected After conclusions

 Test dates (Register 7 days in advance to any test but the first):  31.10.2014  21.11.2014  @ Alpha Auditorium, during 12-16 What is in the test

 5 questions (with sub-questions)  The lectured material during Lectures 1-7  There is not a question from each lecture  there can be questions from the first, last and in between lectures  Concepts that we emphasized over and over during the course  Questions that ask you to compare and relate various concepts  Exercise questions

Failure Case

 The case of a financial institution (using electronic trading).  Or how to loose $172,222 a second for 45 minutes.  A painful bug report described in a SEC document.  New trading software is deployed.  Software executes automated high speed trading orders.  Software is deployed in an environment of older software.  Mistake: deprecated but still active interfaces are reused for new purpose.  Typically new developers are not familiar with internals of older systems.  New software did not completely replace the old system (by mistake).  Old software issues wrong trading orders because of a wrongly used flag in an interface.  It took 45 minutes for technicians to realize what is going on.  With $172,222 loss a second. Success case

 By 1996 Apple reached its bottom.  With no money left (90 days from bankruptcy) and virtually no market share.  Multiple product failures (Newton).  Leadership was reactive (reacting to what they understood of the market).  Instead of being proactive: building products for the future.  By 1997 Apple has its new leadership.  The point of turnaround: a demo to employees on how to build user interfaces in NextStep.  New leadership understood a single most important focus to rebuild the company.  Build software that is component based, object oriented and can be evolved into products.  This understanding came without any education or degree in the field.  And the understanding that this is a long term undertaking. Success case

 Development to repurpose NextStep into OSX starts around 1997.  OSX for servers released in 1999. Basically just a Unix (BSD) core.  First consumer version released in 2001.  Four years of development at a company restarting from bottom.  The end result is a buggy and slow OS.  But one that has the right foundations.  Several releases later the OS is stable, fast and the most user friendly.  The user interface architecture is basically the one devised at Next (1990).  With a lot of evolutionary improvements. Success case

 Successes with other HW products (iPod).  Lets put this huge OS into a mobile phone (2004-2005).  Controversial idea at the time.  Limitations in processor speed, memory and battery life.  The Cocoa framework uses Objective-C a dynamically typed programming language.  Not the best for embedded systems (by the experts of the time).  But the leadership of Apple is not aware that it should be difficult to develop software for mobile.  So they just put together UIKit (slim down version of Cocoa).  And the iPhone by end of 2006.  Demo in January 2007.  Product is so buggy they used a base station behind the curtain just to make sure there is a signal. Success case

 Yet they appreciated the potential.  A new way of building mobile software and user interfaces.  With the same ease as it was already possible for desktop apps.  A number of iterations later the popularity of the product explodes.  Competition is unable to evolve their software to respond.  Market share of all traditional mobile phone makers collapses.  Later, pivoting on an existing platform, Apple releases a new product type.  The iPad denes a new kind of product: tablet.  Yet, this was not new. There were tablets before.  But with advances in hardware, now they could use the NextStep architecture on tablets also (as well as phones).