Software Engineering Natallia Kokash email nkokashliacs nl N

Software Engineering Natallia Kokash email: nkokash@liacs. nl N. Kokash, Software Engineering 1

Software Engineering Agenda n Software Architecture ¨ Definition ¨ Architecture Design ¨ Viewpoints and view models ¨ Architectural styles ¨ Architecture assessment n Software Design ¨ Principles ¨ Methods N. Kokash, Software Engineering 2

Software Engineering Architecture around us Differences: n n Scale Process Cost Schedule N. Kokash, Software Engineering n n Skills and development teams Materials and technologies Stakeholders Risks 3

Software Engineering The Winchester “Mystery” House n n n Built by Sarah Winchester, widow of gun magnate Started in 1884, finished on September 5, 1922: 38 years of construction, 147 builders, 0 architects 160 rooms: 40 bedrooms, 6 kitchens, 2 ball rooms, 950 doors, 10000 window panes, 17 chimneys n n N. Kokash, Software Engineering $5. 5 million in 1922 ≈ $71 million in 2010 65 doors to blank walls, 24 skylights in floors, 13 staircases abandoned 4

Software Engineering Complex structures without architecture n The result is at best baroque. ¨ Clumsiness, inelegance, discord in the structures ¨ Duplication, redundancy, wasted effort, rework, gaps ¨ Poor integration, inconsistency, mismatch n N. Kokash, Software Engineering We simply cannot imagine building a skyscraper without an architecture! 5

Software Engineering The beginning of Software Architecture n 1968/69 NATO conferences: “I think we have something in addition to software engineering [. . ] This is the subject of software architecture. Architecture is different from engineering” N. Kokash, Software Engineering 6

Software Engineering Understanding architecture (1) “The architecture of a software system defines that system in terms of computational components and interactions among those components. ” Shaw & Garlan, Software Architecture: Perspectives on an Emerging Discipline, 1996 N. Kokash, Software Engineering 7

Software Engineering Understanding architecture (2) “The software architecture of a system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. ” Bass, Clements & Kazman, Software Architecture in Practice, 2003 N. Kokash, Software Engineering 8

Software Engineering Understanding architecture statement n procedure ¨ multiple system structures; ¨ externally visible (observable) properties of components. module n (design) pattern architecture N. Kokash, Software Engineering Important issues raised: This definition does not include: ¨ process ¨ rules and guidelines ¨ architectural styles 9

Software Engineering Understanding architecture: popular views n Architecture is high-level design ¨ Architecture ≈ Global design ¨ Architect ≈ Designer n n n Architecture is components and connectors Architecture is overall structure of the system Architecture is the structure, including the principles and guidelines governing their design and evolution over time N. Kokash, Software Engineering 10

Software Engineering Understanding architecture: common elements Defines major components n Defines component relationships (structures) and interactions n Omits content information about components that does not pertain to their interactions n Defines the rationale behind the components and the structure n N. Kokash, Software Engineering 11

Software Engineering Definition 1471 -2000 Software Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution. IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000 N. Kokash, Software Engineering 12

Software Engineering Architectural structures: n n n n n N. Kokash, Software Engineering Module structure Conceptual, or logical structure Process, or coordination structure Physical structure Usage structure Calls structure Data flow Control flow Class structure 13

Software Engineering Software architecture: example N. Kokash, Software Engineering 14

Software Engineering Architecture in IT n Business architecture ¨ Business n model as it relates to an automated solution. Technical architecture ¨ Specific to technology and the use of this technology: . NET, J 2 EE, hardware n Enterprise architecture ¨ Set of principles, policies and technical choices to achieve standardization and integration requirements. ¨ Concerns cross project/solution and communication n Solutions architecture Product-line architecture … N. Kokash, Software Engineering 15

Software Engineering Architecture vs. Design n n Architecture: where non-functional decisions are cast, and functional requirements are partitioned Design: where functional requirements are accomplished non-functional requirements N. Kokash, Software Engineering architecture design 16

Software Engineering Architecture starts early n Architecture represents the set of earliest design decisions ¨ Hardest to change ¨ Most critical to get right n n n Architecture is the first design artifact where a system’s quality attributes are addressed Some qualities are observable via execution: performance, security, availability, functionality, usability And some are not observable via execution: modifiability, portability, reusability, integrability, testability N. Kokash, Software Engineering 17

Software Engineering System attributes n n Performance Availability Usability Security n End user’s view n n n n Maintainability Portability Reusability Testability N. Kokash, Software Engineering n Developer’s view Time to market Cost and benefits Projected life time Targeted market Integration with legacy systems Business community view 18

Software Engineering The role of software architect requirements client, user assess solutions architect developers creates assess prescribe visualize appearance, behavior N. Kokash, Software Engineering architectural design construction, cooperation 19

Software Engineering Adding architecture: easy way stakeholders (few) requirements architecture quality agreement detailed design implementation N. Kokash, Software Engineering development 20

Software Engineering Architecture in the lifecycle n n n Iteration on both functional and quality requirements Many stakeholders involved Balancing of functional and quality requirements stakeholders (many) requirements quality architecture agreement development N. Kokash, Software Engineering 21

Software Engineering Why software architecture is important? Manifests the early set of design decisions n The vehicle for stakeholder communication: n ¨ Architect, requirements engineers, designers (also of other systems), programmers, testers, integrators, maintainers, managers, quality assurance people… n Transferable abstraction of a system ¨ Product lines share a common architecture ¨ Allows for template-based development ¨ Basis for training N. Kokash, Software Engineering 22

Software Engineering Global workflow in architecture design assets architecture ideas synthesis backlog evaluation constraints significant requirements N. Kokash, Software Engineering evaluation results 23

Software Engineering Architecture design n Attribute-Driven Design ¨ Choose module to decompose ¨ Refine this module: n choose architectural drivers (quality is driving force) n choose pattern that satisfies drivers n apply pattern ¨ Repeat n Example: ¨ Top-level: n usability separate user interface three tier architecture ¨ Lower-level, within user interface: n security authenticate users ¨ Lower-level, within data layer: n availability active redundancy N. Kokash, Software Engineering 24

Software Engineering Taking decisions Design problem Sub-problem Decision = best option Design option Problem space Decision space Sub-problem Design option Decision = best option Alternative solutions N. Kokash, Software Engineering Alternative solutions 25

Software Engineering Decision space The space of possible designs that can be achieved by choosing different sets of alternatives. fat-client style client-server client in a separate user interface layer Programmed in Java Programmed in Visual Basic thin-client Programmed in C++ monolithic N. Kokash, Software Engineering no separate user interface layer 26

Software Engineering Types of decisions n Implicit, undocumented ¨ Unaware, tacit, of course knowledge n Explicit, undocumented ¨ Vaporizes n Explicit, explicitly undocumented ¨ Tactical, n over time personal reasons Explicit, documented ¨ Preferred N. Kokash, Software Engineering n Document your decisions ¨ Prevents repeating steps ¨ Explains why this is a good architecture ¨ Emphasizes qualities and criticality for requirements ¨ Provides context and background 27

Software Engineering Elements of a design decision Issues: design issues being addressed n Decision: detailed description of the decision n Status: e. g. , pending, approved n Assumptions: underlying assumptions n Alternatives: what are other options? n Rationale: the why of the decision taken n Implications: e. g. need for further decisions n N. Kokash, Software Engineering 28

Software Engineering Architecture presentation n Building n Overall picture of building (client) n Front view (client, “beauty” committee) n Water supply plan (plumber) n Electrical wiring plan (electrician) N. Kokash, Software Engineering n Software ¨ Powerpoint slides (managers, users, consultants) ¨ UML diagrams, models in specialized languages (ADLs) (technicians) 29

Software Engineering Some more examples… N. Kokash, Software Engineering 30

Software Engineering N. Kokash, Software Engineering 31

Software Engineering N. Kokash, Software Engineering 32

Software Engineering N. Kokash, Software Engineering 33

Software Engineering N. Kokash, Software Engineering Model for architecture description 34

Software Engineering Viewpoint specification n View: a representation of a whole system from the perspective of a related set of concerns. Viewpoint: establishes the purposes and audience for a view and the techniques or methods employed in constructing a view. Viewpoint specification includes: ¨ Viewpoint name ¨ Stakeholders addressed ¨ Concerns addressed ¨ Language, modeling techniques N. Kokash, Software Engineering 35

Software Engineering Kruchten’s 4+1 view model n Logical viewpoint: ¨ ¨ n Supports functional requirements Typically shows the key abstractions (e. g. , classes) Process viewpoint: Shows concurrent aspects at runtime (e. g. , threads and processes) ¨ Takes into account non-functional requirements ¨ n Deployment viewpoint: Maps logical, process, and implementation elements to physical infrastructure ¨ Takes into account non-functional requirements ¨ n Implementation viewpoint: ¨ Shows software packaged in small chunks-program libraries or subsystems N. Kokash, Software Engineering 36

Software Engineering Kruchten’s 4+1 view model n The scenario viewpoint ¨ Consists of a small subset of important scenarios (e. g. , use cases) ¨ Used to show that the elements of the four viewpoints work together seamlessly. n Redundant with the other ones (hence the "+1"), but it plays two critical roles: ¨ acts as a driver to help designers discover architectural elements; ¨ validates and illustrates the architecture design. N. Kokash, Software Engineering 37

Software Engineering Architectural views (Bass et al. ) n Module views ¨ Module is unit of implementation ¨ Decomposition, uses, layered, class n Component and connector (C & C) views ¨ Runtime elements ¨ Process (communication), concurrency, shared data (repository), client-server n Allocation views ¨ Relationship between software elements and environment ¨ Work assignment, deployment, implementation L. Bass et al, Sofware Architecture in Practice, 2003. N. Kokash, Software Engineering 38

Software Engineering Architecture Description Language (ADL) n n n Languages and/or conceptual models to describe and represent system architectures Graphical syntax n Some examples: Hierarchical modeling ¨ Acme ¨ AADL ¨ Rapide ¨ Darwin ¨ Wright N. Kokash, Software Engineering 39

Software Engineering An ADL Example (in ACME) System simple_cs = { Component client = {Port send-request} Component server = {Port receive-request} Connector rpc = {Roles {caller, callee}} Attachments : {client. send-request to rpc. caller; server. receive-request to rpc. callee} } rpc client server caller send-request N. Kokash, Software Engineering callee receive-request 40

Software Engineering ADL: Good and bad Formal way of representing architecture Both human and machine readable Permit analysis of architectures – completeness, consistency, ambiguity, and performance Can support automatic generation of simulations / software systems N. Kokash, Software Engineering Representations are relatively difficult to parse There is not universal agreement on what ADLs should represent Are not supported by commercial tools Optimized toward a particular kind of analysis 41

Software Engineering Architectural styles n An architectural style is a description of component and connector types and a pattern of their runtime control and/or data transfer. n Examples: ¨ main program with subroutines ¨ data abstraction ¨ implicit invocation ¨ pipes and filters ¨ repository (blackboard) ¨ layers of abstraction N. Kokash, Software Engineering 42

Software Engineering Component / connector types Computational • does a computation of some sort • E. g. function, filter Controller • governs time sequence of events • E. g. control module, scheduler Memory • Maintains a collection of persistent data • E. g. data base, file system, symbol table Manager • contains state + operations • State is retained between invocations of operations instantiation N. Kokash, Software Engineering data flow (e. g. pipes) procedure call (including RPC) shared data (e. g. blackboard or shared data base) implicit invocation message passing 43

Software Engineering Alexander’s patterns n n n High buildings have no genuine advantage, except in speculative gains. They are not cheaper, they do not help to create open space, they make life difficult for children, they wreck the open spaces near them. But quite apart from this, empirical evidence shows that they can actually damage people’s minds and feelings. In any urban area, keep the majority of buildings four stories high or less. N. Kokash, Software Engineering 44

Software Engineering General flavor of a pattern IF you find yourself in • THEN for some <reasons>, apply <context>, for <pattern> to construct a solution example <examples>, leading to a <new context> and <other patterns> with <problem> n Structure of architectural style description ¨ Problem: type of problem that the style addresses. ¨ Context: characteristics of the environment that constrain the designer ¨ Solution: in terms of components and connectors (choice not independent), and control structure (order of execution of components) ¨ Variants ¨ Examples N. Kokash, Software Engineering 45

Software Engineering Example: Abstract-data-type n n n Problem: identify and protect related bodies of information. Data representations likely to change. Context: OO-methods which guide the design, OO-languages which provide the class-concept Solution: ¨ system model: component has its own local data ¨ components: managers (servers, objects) ¨ connectors: procedure call (message) ¨ control structure: single thread, decentralized n Variants: caused by language facilities N. Kokash, Software Engineering 46

Software Engineering More architectural styles Layern Layer 2 Layer 1 Client Shared Data Client View Controller n Implicit-invocation n Pipes-and-filters n Layered style n Repository style n Model-View. Controller (MVC) n… n n Model N. Kokash, Software Engineering 47

Software Engineering Architecture assessment n Assess whether architecture meets certain quality goals ¨ e. g. , maintainability, modifiability, reliability, performance n The architecture is assessed, and we hope the results will hold for a system yet to be built Software architecture Properties N. Kokash, Software Engineering implementation properties System Qualities 48

Software Engineering Assessment techniques n Questioning: ¨ How does the system react to various situations? ¨ Use different types of scenarios n use-cases, likely changes, stress situations, risks, far-intothe-future scenarios. . . n Measuring: ¨ Quantitative n measures, metrics, simulation. Preconditions for successful assessment: ¨ Clear goals and requirements for the architecture, controlled scope, key personnel availability, competent evaluation team… N. Kokash, Software Engineering 49

Software Engineering Architecture Tradeoff Analysis Method (ATAM) 0: Preparation 1: Evaluation (1) (evaluation team + decision makers, 1 day) ¨ Present method, business drivers and architecture ¨ Identify architectural approaches/styles ¨ Generate utility tree ¨ Analyze architectural approaches 2: Evaluation (2) (evaluation team + decision makers + stakeholders, 2 days) ¨ Brainstorm and prioritize scenarios ¨ Analyze architectural approaches ¨ Present results 3: Follow up (evaluation team + client) N. Kokash, Software Engineering 50

Software Engineering ATAM: example of utility tree Transaction response time (H, M) Performance Throughput 150 transactions/sec Training Utility Usability Normal operations Maintainability N. Kokash, Software Engineering Database vendor releases new version 51

Software Engineering Output of ATAM n n n Concise presentation of the architecture Articulation of business goals Quality requirements expressed as set of scenarios Architectural decisions mapped to quality requirements Set of sensitivity points, tradeoff points and risks: ¨ Sensitivity point: decision/property critical for certain quality attribute ¨ Tradeoff point: decision/property that affects more than one quality attribute ¨ Risk: decision/property that is a potential problem N. Kokash, Software Engineering 52

Software Engineering Software Architecture Analysis Method (SAAM) 1. Develop scenarios ¨ ¨ 2. 3. Describe architecture(s) Classify scenarios ¨ ¨ 4. 5. for activities the system must support for anticipated changes direct – use requires no change, indirect – use requires change Evaluate indirect scenarios: changes and cost Reveal scenario interaction (i. e. , scenarious that require changes in the same component) n n 6. Interaction exposes allocation of functionality to the design Architecture might not be at right level of detail Overall evaluation N. Kokash, Software Engineering 53

Software Engineering SUMMARY Architectural styles and design pattern describe (how are things done) as well as prescribe (how should things be done) n Architecture supports stakeholder communication, early evaluation of design, transferable abstraction n N. Kokash, Software Engineering 54

Software Engineering Homework Read chapter 11 n Design the architecture of Image 2 UML system n ¨ Use rup_sad. dot template N. Kokash, Software Engineering 55

Software Engineering (3 rd Ed. ) n n n n n N. Kokash, Software Engineering 1. Introduction 2. Introduction to Software Engineering Management 3. The Software Life Cycle Revisited 4. Configuration Management 5. People Management and Team Organization 6. On Managing Software Quality 7. Cost Estimation 8. Project Planning and Control 9. Requirements Engineering 10. Modeling 11. Software Architecture 12. Software Design 13. Software Testing 14. Software Maintenance 17. Software Reusability 18. Component-Based Software Engineering 19. Service Orientation 20. Global Software Development 56