Software Architecture. Schahram Dustdar Distributed Systems Group TU Wien

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "Software Architecture. Schahram Dustdar Distributed Systems Group TU Wien"

Transcription

1 Software Architecture Schahram Dustdar Distributed Systems Group TU Wien 1

2 Main Topics Software Architecture: Introduction Architecture and Architecture Disciplines Architectural Requirements Architectural Principles Architectural Styles and Patterns Important Architectural Styles and Patterns Modeling Architectures Model-Driven Design and Development Architectural Views Architectural Decisions Architecture in the Organization 2

3 SOFTWARE ARCHITECTURE: INTRODUCTION 3

4 Main Goals Provide an orientation on architecture Improve the quality of the software Understand architectural thinking 4

5 Typical process of developing software developer s point of view Starting point: A wishlist Next step: A concept is created Then: Changes are needed Deviations from the concept are necessary Result: Big Ball of Mud 5

6 Big Ball of Mud In computer programming, Big Ball of Mud is a term for a system or computer program that has no real distinguishable architecture. 6

7 Analogy in Civil Architecture 7

8 Many IT-Projects Fail The big ball of mud scenario is not exaggerated Most of the IT projects fail more or less E.g.: Only 16 % of the projects in the study by [Standish 1994] have been concluded successfully Examples for failing are [Yourdon 2004]: Exceeding the budget Exceeding the time Customers are not satisfied with the delivered product The project gets cancelled 8

9 Inspiration from Civil Architecture In analogy to civil architecture, software architecture aims to manage the complexity of the systems we build 9

10 ARCHITECTURE AND ARCHITECTURE DISCIPLINES 10

11 Civil Architecture as a Starting Point Architecture Definition (American Heritage Dictionary): The art and science of designing and erecting buildings A style and method of design and construction Orderly arrangement of parts That is, architecture includes: The structure of a building or software system The act of designing this structure 11

12 What is Software Architecture? Architecture does not specify the details, but the load carrying components Think of coarse-grained components and subsystems rather than of individual classes an algorithms Architecture reaches from analysis of the problem to the realization of the solution Architecture aims to make complexity manageable Architecture deals with decisions that have system-wide consequences 12

13 Definition: What is Software Architecture? A software system s architecture is the set of principal design decisions about the system Software architecture is the blueprint for a software system s construction and evolution Design decisions encompass every facet of the system under development Structure Behavior Interaction There are numerous definitions of SW architecture: Non-functional properties 13

14 What is Principal? Principal implies a degree of importance that grants a design decision architectural status It implies that not all design decisions are architectural That is, they do not necessarily impact a system s architecture How one defines principal will depend on what the stakeholders define as the system goals 14

15 Other Definitions of Software Architecture Perry and Wolf Software Architecture = { Elements, Form, Rationale } what how why Shaw and Garlan Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. Kruchten Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics. 15

16 Temporal Aspect Architecture has a temporal aspect At any given point in time the system has only one architecture A system s architecture will change over time 16

17 Prescriptive vs. Descriptive Architecture A system s prescriptive architecture captures the design decisions made prior to the system s construction It is the as-conceived or as-intended architecture A system s descriptive architecture describes how the system has been built It is the as-implemented or as-realized architecture 17

18 Architectural Evolution When a system evolves, ideally its prescriptive architecture is modified first In practice, the system and thus its descriptive architecture is often directly modified This happens because of Developer sloppiness Perception of short deadlines which prevent thinking through and documenting Lack of documented prescriptive architecture Need or desire for code optimizations Inadequate techniques or tool support 18

19 Implementation-Level View of an Application Complex and virtually incomprehensible! 19 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

20 Deployment A software system cannot fulfill its purpose until it is deployed Executable modules are physically placed on the hardware devices on which they are supposed to run The deployment view of an architecture can be critical in assessing whether the system will be able to satisfy its requirements Possible assessment dimensions Available memory Power consumption Required network bandwidth 20

21 Software Architecture s Elements A software system s architecture typically is not (and should not be) a uniform monolith A software system s architecture should be a composition and interplay of different elements Processing Data, also referred as information or state Interaction 21

22 Components Elements that encapsulate processing and data in a system s architecture are referred to as software components Definition A software component is an architectural entity that encapsulates a subset of the system s functionality and/or data restricts access to that subset via an explicitly defined interface has explicitly defined dependencies on its required execution context Components typically provide application-specific services 22

23 Connectors In complex systems interaction may become more important and challenging than the functionality of the individual components Definition A software connector is an architectural building block tasked with effecting and regulating interactions among components In many software systems connectors are usually simple procedure calls or shared data accesses Much more sophisticated and complex connectors are possible! Connectors typically provide applicationindependent interaction facilities 23

24 Examples of Connectors Procedure call connectors Shared memory connectors Message passing connectors Streaming connectors Distribution connectors Wrapper/adaptor connectors 24

25 Configurations Components and connectors are composed in a specific way in a given system s architecture to accomplish that system s objective Definition An architectural configuration, or topology, is a set of specific associations between the components and connectors of a software system s architecture 25

26 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 26

27 Architectural Patterns Definition An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem and parameterized to account for different software development contexts in which that problem appears A widely used pattern in modern distributed systems is the three-tiered system pattern Science Banking E-commerce Reservation systems 27

28 Three-Tiered Pattern Front Tier Contains the user interface functionality to access the system s services Middle Tier Contains the application s major functionality Back Tier Contains the application s data access and storage functionality 28 Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; 2008 John Wiley & Sons, Inc. Reprinted with permission.

29 Architectural Models, Views, and Visualizations Architecture Model An artifact documenting some or all of the architectural design decisions about a system Architecture Visualization A way of depicting some or all of the architectural design decisions about a system to a stakeholder Architecture View A subset of related architectural design decisions 29

30 Architectural design Architectural Processes Architecture modeling and visualization Architecture-driven system analysis Architecture-driven system implementation Architecture-driven system deployment, runtime redeployment, and mobility Architecture-based design for non-functional properties, including security and trust Architectural adaptation 30

31 Stakeholders in a System s Architecture Architects Developers Testers Managers Customers Users Vendors 31

32 Software Architecture as a Discipline Architecture does not only encompass the architectural description of a system (structure) But also the activities of the architect Sometimes called the architecting of a system This includes the work with all the stakeholders of the system 32

33 Influencing factors Functional requirements Non-functional requirements Organizational factors Cultural factors Architecture Social factors 33

34 The Architect s Tasks and Roles Architectures and architecture disciplines Architectural perspectives Architectural means Architect Architectural requirements Organizations and individuals Architectural methods and procedures 34

35 Different system views (domain view, logical view, realization view, ) are modeled using UML diagrams in the documentation Functional requirements Non-functional requirements: Extensibility, Changeability, System should be well tested Example: Small student Web project in Java Domain model is designed first Refined to technical model Mapped to platforms (technologies) Architectural perspectives Architectural requirements Architectures and architecture disciplines Architect Architectural methods and procedures 35 Architectural means Organizations and individuals Iterative Development Agile Approach Programming language: Java Technologies: Hibernate, Web Server Concept: Object- Orientation UML for modeling in the documentation 2 Students: Programmers for functional building blocks 1 Student: Planning, documentation, and integration Teacher ~ Customer role

36 Architectural Refinement Domain Architecture structures Domain Components uses uses Technical Architecture structures Technical Components uses uses Platform Architecture structures 36 Platform Components

37 Domain Architecture The domain architecture reflects the problem space for which the system is developed Driven by the character of the domain Driven by the functional requirements Example: In an order fulfillment system, domain components for order entry, order management, customer management can be identified 37

38 Technical Architecture The technical architecture is domain-neutral and deals with realizing the non-functional requirements Examples: Logging, Auditing, Security, Data Consistency, Data Persistence, Transaction Management Technical components use services of the platform They can be used platform-neutrally by domain components 38

39 Platform Architecture The platform architecture provides services for executing software components Can contain hardware and/or software components Example: JEE is a component platform that uses itself various operating system and hardware platforms 39

40 Other Architecture Disciplines in IT Software architecture is only one of the architecture disciplines in IT IT systems get more and more complex Hence a specialization is necessary Software Architecture Network Architecture Integration Architecture Data Architecture Security Architecture System Management Architecture System Enterprise Architecture 40

41 Components A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to third-party composition. -- Clemens Szyperski, Component Software This definition encompasses many different concepts, such as: Subsystems DLLs JavaBeans ActiveX Controls JEE-Components.NET-Components Components in scripting languages (Tcl, Python, Perl)... 41

42 ARCHITECTURAL REQUIREMENTS 42

43 Architecture is always a compromise Marcus Vitruvius Pollio (born c BC, died after c. 15 BC) was a Roman writer, architect and engineer [ ] Vitruvius is famous for asserting in his book De architectura that a structure must exhibit the three qualities of firmitas, utilitas, venustas that is, it must be strong or durable, useful, and beautiful. 43

44 Architectural Requirements The system must be designed to fulfill its requirements They must be properly balanced They have a different influence on the architecture Architectural requirements can be seen as forces that influence and form a system design Requirement Requirement Requirement Architecture Requirement Requirement Requirement Requirement 44

45 Requirements and their Properties A requirement is a capability of a system needed by a user of the system to solve a problem or reach a goal.... is a capability of a system to fulfill a contract, a standard, a specification, or another formal document. A requirement should be... correct in the view of the users and stakeholders of the system implementable with the given resources and in the given environment unambiguously defined testable 45

46 Kinds of Architectural Requirements Organization-Level Requirements based on System-Level Requirements based on Component-Level Requirements Functional Requirements Non-Functional Requirements Design Time Requirements Runtime Requirements Organizational Environment Requirements abstraction level 46

47 Functional Requirements Functional Requirements define the functionalities needed: They define what a system is supposed to accomplish For example they can be modeled using use cases Create Diagram Create Class Diagram Create Use Case Diagram Save Diagram Modeler Create Object Diagram Open Diagram Create Sequence Diagram Example: Use Case Diagram for a modelling tool 47 Create Activity Diagram

48 Example using the Basic Use Case Template by Cockburn Use Case: 5 Buy Goods CHARACTERISTIC INFORMATION Goal in Context: Buyer issues request directly to our company, expects goods shipped and to be billed. Scope: Company Level: Summary Preconditions: We know Buyer, their address, etc. Success End Condition: Buyer has goods, we have money for the goods. Failed End Condition: We have not sent the goods, Buyer has not spent the money. Primary Actor: Buyer, any agent (or computer) acting for the customer Trigger: purchase request comes in. MAIN SUCCESS SCENARIO 1. Buyer calls in with a purchase request. 2. Company captures buyer s name, address, requested goods, etc. 3. Company gives buyer information on goods, prices, delivery dates, etc. 4. Buyer signs for order. 5. Company creates order, ships order to buyer. 6. Company ships invoice to buyer. 7. Buyers pays invoice. EXTENSIONS 3a. Company is out of one of the ordered items: 3a1. Renegotiate order. 48 4a. Buyer pays directly with credit card: 4a1. Take payment by credit card (use case 44) 7a. Buyer returns goods: 7a. Handle returned goods (use case 105) SUB-VARIATIONS 1. Buyer may use phone in, fax in, use web order form, electronic interchange 7. Buyer may pay by cash or money order check credit card RELATED INFORMATION Priority: top Performance Target: 5 minutes for order, 45 days until paid Frequency: 200/day Superordinate Use Case: Manage customer relationship (use case 2) Subordinate Use Cases: Create order (use case 15) Take payment by credit card (use case 44) Handle returned goods (use case 105) Channel to primary actor: may be phone, file or interactice Secondary Actors: credit card company, bank, shipping service Channels to Secondary Actors: OPEN ISSUES What happens if we have part of the order? What happens if credit card is stolen? SCHEDULE Due Date: release 1.0 Sample in table format: From: Basic+use+case+template

49 Non-functional Requirements Non-functional requirements (NFR) define expectations or criteria that can be used to judge the operation of a system NFRs with direct implications: qualities or quality attributes Examples: Performance, Extensibility, Reusability,... NFRs with indirect implications: Standards, parameters, or conditions that must be considered or reached Examples: Budget, Regulations, Legislatives, Business Policies 49

50 Relevance of NFRs Fulfilling the NFRs is essential to the acceptance of the functionality of the system Nevertheless NFRs are often neglected The focus is often clearly on the functional requirements Major task of the architect: Sensitize the stakeholders for the importance of the NFRs NFRs should be considered even in early phases of architecting 50

51 ARCHITECTURAL PRINCIPLES 51

52 Architectural Principles Given the many influencing factors on an architecture: How to decide whether an architecture is good? It is difficult to say that an architecture is good or bad per se It just fulfills its functional and non-functional requirements better or worse But there are principles that can help when designing a software architecture 52

53 Coupling Coupling measures the dependencies among the components of an architecture Characterizes the interactions of the components Can be measured by counting the relationships among components There are many kinds of coupling that can be measured, such as: Coupling of classes Coupling of runtime objects Coupling of modules or components Coupling of HW components 53

54 Principle of Loose Coupling The coupling of components should be kept as low as possible 1 st Goal: Keep the complexity of structures low The less a components is coupled with other components, the easier it is understandable on its own 2 nd Goal: Increase the changeability of the architecture The less components are affected by a change in a component, the easier it is to do a change locally in a component without looking at the environment 54

55 Cohesion Cohesion measures the dependencies within a component A class consists of methods and variables Components can have sub-components 55

56 Principle of High Cohesion The cohesion of a component should be as high as possible As in loose coupling, the goal is to support understandability and changeability of components: If a component contains all elements that are needed to understand or change it, it can be understood or changed without looking at other components 56

57 Interdependence: Coupling and Cohesion Most often: the higher the cohesion of individual components, the lower the coupling between the components 57

58 Principle of Design for Change Design for change means to plan for foreseeable changes when designing an architecture Requirements that are likely to arise can be considered during planning Inconsistencies and unclear parts of requirement specifications can requirements that are likely to arise Experiences from designing similar architectures can be considered when designing a new architecture 58

59 Risks of Design for Change A more changeable design can also bear risks More development time High costs for more elaborate designs More implementation effort More flexible architectures often consume more resources (memory, performance) 59

60 Separation of Concerns Principle Different aspects of a problem should be separated from each other, and each aspect of the problem should be treated on its own Main kind of area of Separation of Concerns in SW architecture: Modularization Separate a software system into a structure of components 60

61 Other Kinds of Separation of Concerns in SW Architecture Separation of requirements Separation of a complex architecture model into views Separation of organizational responsibilities Separation of process into sub-processes Multi-dimensional separation of concerns (Aspect- Orientation) 61

62 Information Hiding Principle To a client present only the really necessary parts of the whole information and hide all the rest Goal: Reduction of the complexity of a SW architecture. Example: Hiding implementation details behind an interface 62

63 Example: Information Hiding using the Facade Pattern 63

64 Other Important Architecture Principles Abstraction Principles are using abstractions to make a complex problem understandable by identifying important aspects and neglecting less important ones E.g. Abstraction Principles with a focus on interfaces: Explicit Interfaces Segregation of Interface and Implementation Many other more special architecture principles: Modularization Principle (see above) Traceability Principle Self Documentation Principle Incremental Evolution Principle 64

65 Many thanks for your attention! Schahram Dustdar Distributed Systems Group TU Wien 65

Software Architecture

Software Architecture Software Architecture Lecture 2 Basic Concepts Rob Pettit George Mason University What is Software Architecture?! Definition:! A software system s architecture is the set of principal design decisions

More information

Basic Concepts. Software Architecture Lecture 3. Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

Basic Concepts. Software Architecture Lecture 3. Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Basic Concepts Software Architecture Lecture 3 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Formally define software architecture Distinguish

More information

Software Architecture

Software Architecture Software Architecture Software Engineering Alessio Gambi - Saarland University These slides are based the slides from Cesare Pautasso and Christoph Dorn, and updated from various sources. References and

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

The Role of the Software Architect

The Role of the Software Architect IBM Software Group The Role of the Software Architect Peter Eeles peter.eeles@uk.ibm.com 2004 IBM Corporation Agenda Architecture Architect Architecting Requirements Analysis and design Implementation

More information

Software architecture: Domain-Specific Software Architecture and Architectural Patterns

Software architecture: Domain-Specific Software Architecture and Architectural Patterns 2IW80 Software specification and architecture Software architecture: Domain-Specific Software Architecture and Architectural Patterns Alexander Serebrenik Before we start A way of looking at a system from

More information

RUP Design Workflow. Michael Fourman Cs2 Software Engineering

RUP Design Workflow. Michael Fourman Cs2 Software Engineering RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall

More information

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces

Decomposition into Parts. Software Engineering, Lecture 4. Data and Function Cohesion. Allocation of Functions and Data. Component Interfaces Software Engineering, Lecture 4 Decomposition into suitable parts Cross cutting concerns Design patterns I will also give an example scenario that you are supposed to analyse and make synthesis from The

More information

Analysis of Software Architectures

Analysis of Software Architectures Analysis of Software Architectures Software Architecture Lecture 13 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. Learning Objectives Define architectural analysis

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

Data Modeling Basics

Data Modeling Basics Information Technology Standard Commonwealth of Pennsylvania Governor's Office of Administration/Office for Information Technology STD Number: STD-INF003B STD Title: Data Modeling Basics Issued by: Deputy

More information

Software Design and Class Diagrams

Software Design and Class Diagrams Software Design and Class Diagrams Massimo Felici Software Design 1 The SEOC course is concerned with software design in terms of objects and components, in particular, object-oriented design Object-oriented

More information

Software Engineering

Software Engineering Software Engineering Lecture 06: Design an Overview Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 35 The Design Phase Programming in

More information

Developing the Architectural Framework for SOA Adoption

Developing the Architectural Framework for SOA Adoption Developing the Architectural Framework for SOA Adoption Oliver Sims Enterprise Architect oliver.sims@open-it.co.uk Copyright Open-IT Limited 2005 Agenda Service Orientation just a good technology? The

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Version 9 2 SOA-2 Overview Ok, now we understand the Web Service technology, but how about Service Oriented Architectures? A guiding analogy Terminology excursion Service,

More information

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011 Use Cases Massimo Felici Use Cases 1 Support requirements engineering activities and the requirement process Capture what a system is supposed to do, i.e., systems functional requirements Describe sequences

More information

Basic Use Case Template Alistair Cockburn home page:

Basic Use Case Template Alistair Cockburn   home page: Document: TR.96.03a This Version Date: October 26, 1998 Version: 2 Previous Version Date: April 26, 1996 Basic Use Case Template Alistair Cockburn email: arc@acm.org home page: http://alistair.cockburn.us

More information

Software Development in the Large!

Software Development in the Large! Software Development in the Large! Peter Eeles Executive IT Architect, IBM peter.eeles@uk.ibm.com IBM Rational Software Development Conference 2007 2007 IBM Corporation Agenda IBM Rational Software Development

More information

Engineering Process Software Qualities Software Architectural Design

Engineering Process Software Qualities Software Architectural Design Engineering Process We need to understand the steps that take us from an idea to a product. What do we do? In what order do we do it? How do we know when we re finished each step? Production process Typical

More information

Software Engineering. Software Engineering. Component-Based. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Engineering. Component-Based. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Component-Based Software Engineering Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To explain that CBSE is concerned with developing standardised components

More information

Stock Trader System. Architecture Description

Stock Trader System. Architecture Description Stock Trader System Architecture Description Michael Stevens mike@mestevens.com http://www.mestevens.com Table of Contents 1. Purpose of Document 2 2. System Synopsis 2 3. Current Situation and Environment

More information

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 6, July-August 2008 Aligning IT to Business Through Architecture Mahesh H.

More information

Object-Oriented Design Guidelines

Object-Oriented Design Guidelines Adaptive Software Engineering G22.3033-007 Session 8 Sub-Topic 3 Presentation Object-Oriented Design Guidelines Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute

More information

An Approach to Software Architecture Description Using UML

An Approach to Software Architecture Description Using UML An Approach to Software Architecture Description Using UML Henrik Bærbak Christensen, Aino Corry, and Klaus Marius Hansen Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N,

More information

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/

Architecture. Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Architecture Reda Bendraou reda.bendraou{{@}}lip6.fr http://pagesperso-systeme.lip6.fr/reda.bendraou/ Some slides were adapted from L. Osterweil, B. Meyer, and P. Müller material Reda Bendraou LI386-S1

More information

Software Architecture Action Guide. Why do we care about Software Architecture?

Software Architecture Action Guide. Why do we care about Software Architecture? Software Action Guide Dana Bredemeyer Bredemeyer Consulting Tel: (812) 335-1653 Fax: (812) 335-1652 Email: dana@bredemeyer.com Web: Why do we care about Software? Because we want to be a dominant player

More information

Robust Object Oriented System Analysis

Robust Object Oriented System Analysis Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.

More information

Requirements engineering and quality attributes

Requirements engineering and quality attributes Open Learning Universiteit Unit 2 Learning Unit 2 Requirements engineering and quality attributes Contents Introduction............................................... 21 2.1 Important concepts........................................

More information

Analysis of Software Architectures

Analysis of Software Architectures Analysis of s Lecture 13 Copyright Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved. What Is Architectural Analysis? Architectural analysis is the activity of discovering important

More information

Business Modeling with UML

Business Modeling with UML Business Modeling with UML Hans-Erik Eriksson and Magnus Penker, Open Training Hans-Erik In order to keep up and be competitive, all companies Ericsson is and enterprises must assess the quality of their

More information

Architecture Differentiation Enterprise versus Solution Architecture

Architecture Differentiation Enterprise versus Solution Architecture Enterprise versus Solution Architecture Architecture Handbook core components (view model) View model is holistic, interlinked and takes EA into account Complementary material includes check-lists, training

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Basic Unified Process: A Process for Small and Agile Projects

Basic Unified Process: A Process for Small and Agile Projects Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.

More information

Exploring Architectural Design Decision Management Paradigms for Global Software Development

Exploring Architectural Design Decision Management Paradigms for Global Software Development Exploring Architectural Design Decision Management Paradigms for Global Software Development Meiru Che, Dewayne E. Perry Department of Electrical & Computer Engineering The University of Texas at Austin

More information

Aerospace Software Engineering

Aerospace Software Engineering 16.35 Aerospace Software Engineering Software Architecture The 4+1 view Patterns Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Why Care About Software Architecture? An architecture provides a vehicle

More information

Table of Contents. CHAPTER 1 Web-Based Systems 1. CHAPTER 2 Web Engineering 12. CHAPTER 3 A Web Engineering Process 24

Table of Contents. CHAPTER 1 Web-Based Systems 1. CHAPTER 2 Web Engineering 12. CHAPTER 3 A Web Engineering Process 24 Table of Contents CHAPTER 1 Web-Based Systems 1 The Web 1 Web Applications 2 Let s Introduce a Case Study 3 Are WebApps Really Computer Software? 4 Are the Attributes of WebApps Different from the Attributes

More information

Introduction to Service Oriented Architectures (SOA)

Introduction to Service Oriented Architectures (SOA) Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction

More information

What Is the Java TM 2 Platform, Enterprise Edition?

What Is the Java TM 2 Platform, Enterprise Edition? Page 1 de 9 What Is the Java TM 2 Platform, Enterprise Edition? This document provides an introduction to the features and benefits of the Java 2 platform, Enterprise Edition. Overview Enterprises today

More information

Non-Functional Requirements

Non-Functional Requirements IBM Software Group Non-Functional Requirements Peter Eeles peter.eeles@uk.ibm.com Agenda IBM Software Group Rational software Definitions Types of requirement Classifying requirements Capturing NFRs Summary

More information

Architectural Governance

Architectural Governance Architectural Governance Grady Booch IBM Fellow 1 Outline The context for architecture Architecture defined Representing architecture Architectural governance Organizational best practices 2 The context

More information

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES Robert M. Bruckner Vienna University of Technology bruckner@ifs.tuwien.ac.at Beate List Vienna University of Technology list@ifs.tuwien.ac.at

More information

A complete software development process of a general report publication service implemented using Web Services

A complete software development process of a general report publication service implemented using Web Services A complete software development process of a general report publication service implemented using Web Services Anders Nilsson & Klas Fahlberg February 1, 2008 Master s Thesis in Computing Science, 2*30

More information

A Framework for Software Product Line Engineering

A Framework for Software Product Line Engineering Günter Böckle Klaus Pohl Frank van der Linden 2 A Framework for Software Product Line Engineering In this chapter you will learn: o The principles of software product line subsumed by our software product

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Service Oriented Analysis and Design (SOAD) in Practice Part 4 Adomas Svirskas Vilnius University October 2005 Agenda Service identification and definition Business process

More information

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK

Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK IBM Software Group Requirement Management with the Rational Unified Process RUP practices to support Business Analyst s activities and links with BABoK Jean-Louis Maréchaux Software IT Specialist IBM Rational

More information

Component Based Software Engineering: A Broad Based Model is Needed

Component Based Software Engineering: A Broad Based Model is Needed Component Based Software Engineering: A Broad Based Model is Needed Allen Parrish (parrish@cs.ua.edu) Brandon Dixon (dixon@cs.ua.edu) David Hale (dhale@alston.cba.ua.edu) Department of Computer Science

More information

Scope Planning (IS PM 5. Lecture, 2012 Spring)

Scope Planning (IS PM 5. Lecture, 2012 Spring) Scope Planning Project success is determined by its usefulness or profitability: in increase of revenue in savings of costs The main reason to change existent information system is to get more benefits

More information

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g

Systems Integration: Co C mp m onent- t bas a e s d s o s ftw ft a w r a e r e ngin i eeri r n i g Systems Integration: Component-based software engineering Objectives To explain that CBSE is concerned with developing standardised components and composing these into applications To describe components

More information

SOA REFERENCE ARCHITECTURE: WEB TIER

SOA REFERENCE ARCHITECTURE: WEB TIER SOA REFERENCE ARCHITECTURE: WEB TIER SOA Blueprint A structured blog by Yogish Pai Web Application Tier The primary requirement for this tier is that all the business systems and solutions be accessible

More information

Agile Modeling and Design of Service-Oriented Component Architecture

Agile Modeling and Design of Service-Oriented Component Architecture Agile Modeling and Design of Service-Oriented Component Architecture Zoran Stojanovic, Ajantha Dahanayake, Henk Sol Systems Engineering Group, Faculty of Technology, Policy and Management, Delft University

More information

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013

D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 D6 INFORMATION SYSTEMS DEVELOPMENT. SOLUTIONS & MARKING SCHEME. June 2013 The purpose of these questions is to establish that the students understand the basic ideas that underpin the course. The answers

More information

Architectural Design

Architectural Design Software Engineering Architectural Design 1 Software architecture The design process for identifying the sub-systems making up a system and the framework for sub-system control and communication is architectural

More information

Principles Leading to Good Design. Techniques for making design decisions. Using cost-benefit analysis to choose. Writing a Good Design Document

Principles Leading to Good Design. Techniques for making design decisions. Using cost-benefit analysis to choose. Writing a Good Design Document Principles Leading to Good Design Techniques for making design decisions Overall goals of good design: Increasing profit by reducing cost and increasing revenue Ensuring that we actually conform with the

More information

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones.

E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones. E-Commerce Supply Chain Management Domain Research and Standard Architectures Kunal Chopra, Jeff Elrod, Bill Glenn, Barry Jones Introduction E-Commerce Supply Chain Management involves the co-ordination

More information

Requirements Traceability. Mirka Palo

Requirements Traceability. Mirka Palo Requirements Traceability Mirka Palo Seminar Report Department of Computer Science University of Helsinki 30 th October 2003 Table of Contents 1 INTRODUCTION... 1 2 DEFINITION... 1 3 REASONS FOR REQUIREMENTS

More information

Software Engineering Reference Framework

Software Engineering Reference Framework Software Engineering Reference Framework Michel Chaudron, Jan Friso Groote, Kees van Hee, Kees Hemerik, Lou Somers, Tom Verhoeff. Department of Mathematics and Computer Science Eindhoven University of

More information

Understanding Service-Orientation Part II: The Principles

Understanding Service-Orientation Part II: The Principles by Raj Balasubramanian, Enterprise IT Architect for IBM Software Group, Benjamin Carlyle, Architect in the Rail industry, Cesare Pautasso Assistant professor in the new Faculty of Informatics at the University

More information

SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q. Exam Code: S90-03A. Exam Name: SOA Design & Architecture

SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q. Exam Code: S90-03A. Exam Name: SOA Design & Architecture SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q Number: S90-03A Passing Score: 800 Time Limit: 120 min File Version: 14.5 http://www.gratisexam.com/ Exam Code: S90-03A Exam Name:

More information

Structuring Product-lines: A Layered Architectural Style

Structuring Product-lines: A Layered Architectural Style Structuring Product-lines: A Layered Architectural Style Tommi Myllymäki, Kai Koskimies, and Tommi Mikkonen Institute of Software Systems, Tampere University of Technology Box 553, FIN-33101 Tampere, Finland

More information

A standards-based approach to application integration

A standards-based approach to application integration A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist Macnair@us.ibm.com Copyright IBM Corporation 2005. All rights

More information

Introduction to OpenUP (Open Unified Process)

Introduction to OpenUP (Open Unified Process) Introduction to OpenUP (Open Unified Process) Different projects have different process needs. Typical factors dictate the needs for a more formal or agile process, such as team size and location, architecture

More information

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 20-21 The Unified Process Dynamic dimension Two dimensions Content

More information

Unified Modeling Language (UML) for Database Systems and Computer Applications

Unified Modeling Language (UML) for Database Systems and Computer Applications Unified Modeling Language (UML) for Database Systems and Computer Applications Sunguk Lee * Research Institute of Industrial Science and Technology Pohang, Korea sunguk@rist.re.kr *Correspondent Author:

More information

S-Tropos: An Iterative SPEM-Centric Software Project Management Process

S-Tropos: An Iterative SPEM-Centric Software Project Management Process S-Tropos: An Iterative SPEM-Centric Software Project Management Process Yves Wautelet, Manuel Kolp, Youssef Achbany IAG Institut d Administration et de Gestion, ISYS Unité de Systèmes d Information, Université

More information

Service Oriented Architecture 1 COMPILED BY BJ

Service Oriented Architecture 1 COMPILED BY BJ Service Oriented Architecture 1 COMPILED BY BJ CHAPTER 9 Service Oriented architecture(soa) Defining SOA. Business value of SOA SOA characteristics. Concept of a service, Enterprise Service Bus (ESB) SOA

More information

Introduction to software architecture

Introduction to software architecture Learning Unit 1 Introduction to software architecture Contents Introduction............................................... 7 1.1 What is software architecture?................................. 7 1.1.1

More information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 4 Software Lifecycle and Performance Analysis Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and

More information

Course Description. Course Audience. Course Outline. Course Page - Page 1 of 14

Course Description. Course Audience. Course Outline. Course Page - Page 1 of 14 Course Page - Page 1 of 14 Solution Architecture Training: SA Practitioner's Guide (Extended) BSP-2325 Length: 4 days Price: $ 2,995.00 Course Description The course covers stakeholder identification,

More information

VAIL-Plant Asset Integrity Management System. Software Development Process

VAIL-Plant Asset Integrity Management System. Software Development Process VAIL-Plant Asset Integrity Management System Software Development Process Document Number: VAIL/SDP/2008/008 Engineering For a Safer World P u b l i c Approved by : Ijaz Ul Karim Rao Revision: 0 Page:2-of-15

More information

A Model-Driven Approach for Building Customized Distributed Applications

A Model-Driven Approach for Building Customized Distributed Applications A Model-Driven Approach for Building Customized Distributed Applications By John Pompeii and Scott Danforth Secant Technologies, Inc. - - April 25, 2001 A Model-Driven Approach for Building Customized

More information

Sistemi ICT per il Business Networking

Sistemi ICT per il Business Networking Corso di Laurea Specialistica Ingegneria Gestionale Sistemi ICT per il Business Networking Software Development Processes Docente: Vito Morreale (vito.morreale@eng.it) 17 October 2006 1 The essence of

More information

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model

Software Design. Design (I) Software Design Data Design. Relationships between the Analysis Model and the Design Model Software Design Design (I) Software Design is a process through which requirements are translated into a representation of software. Peter Lo CS213 Peter Lo 2005 1 CS213 Peter Lo 2005 2 Relationships between

More information

Software Service Engineering Architect s Dream or Developer s Nightmare?

Software Service Engineering Architect s Dream or Developer s Nightmare? Software Service Engineering Architect s Dream or Developer s Nightmare? Gregor Hohpe Google, 1600 Amphitheatre Parkway, Mountain View, CA 94043 gregor@hohpe.com Abstract. Architectural principles such

More information

11 Tips to make the requirements definition process more effective and results more usable

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Applying Agile Methods in Rapidly Changing Environments

Applying Agile Methods in Rapidly Changing Environments Applying Agile Methods in Changing Environments 7/23/2002 1 Applying Agile Methods in Rapidly Changing Environments Peter Kutschera IBM Unternehmensberatung GmbH Am Fichtenberg 1, D-71803 Herrenberg Steffen

More information

Developing SOA solutions using IBM SOA Foundation

Developing SOA solutions using IBM SOA Foundation Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this

More information

Dan Cohen Microsoft Consulting services Microsoft Israel

Dan Cohen Microsoft Consulting services Microsoft Israel Dan Cohen Microsoft Consulting services Microsoft Israel email: danco@microsoft.com Agenda Learn key architectural styles: client/server layered architecture component-based architecture message-bus architecture

More information

Agile Software Engineering Practice to Improve Project Success

Agile Software Engineering Practice to Improve Project Success Agile Software Engineering Practice to Improve Project Success Dietmar Winkler Vienna University of Technology Institute of Software Technology and Interactive Systems dietmar.winkler@qse.ifs.tuwien.ac.at

More information

Web Application Architectures

Web Application Architectures Web Engineering Web Application Architectures Copyright 2013 Ioan Toma & Srdjan Komazec 1 Where we are? # Date Title 1 5 th March Web Engineering Introduction and Overview 2 12 th March Requirements Engineering

More information

Di 6.1a. Warum naive SOA scheitert Ein Erfahrungsbericht. Adam Bien. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich

Di 6.1a. Warum naive SOA scheitert Ein Erfahrungsbericht. Adam Bien. January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Di 6.1a January 26-30, 2009, Munich, Germany ICM - International Congress Centre Munich Warum naive SOA scheitert Ein Erfahrungsbericht Adam Bien How To Kill a SOA Project Early? [Warum naive SOA scheitert]

More information

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software...

1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java. The Nature of Software... 1.1 The Nature of Software... Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering Software is intangible Hard to understand

More information

A Business Process Driven Approach for Generating Software Modules

A Business Process Driven Approach for Generating Software Modules A Business Process Driven Approach for Generating Software Modules Xulin Zhao, Ying Zou Dept. of Electrical and Computer Engineering, Queen s University, Kingston, ON, Canada SUMMARY Business processes

More information

The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures

The MCSE Methodology. overview. the mcse design process. if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE Methodology overview if a picture is worth a thousand words, an executable model is worth a thousand pictures The MCSE methodology the mcse methodology (méthodologie de conception des Systèmes

More information

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The Service-Oriented Modeling Framework

More information

Customer Bank Account Management System Technical Specification Document

Customer Bank Account Management System Technical Specification Document Customer Bank Account Management System Technical Specification Document Technical Specification Document Page 1 of 15 Table of Contents Contents 1 Introduction 3 2 Design Overview 4 3 Topology Diagram.6

More information

Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing

Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Presented by : Ajay Budhraja, Chief, Enterprise Services ME (Engg), MS (Mgmt), PMP, CICM, CSM,

More information

Fourth generation techniques (4GT)

Fourth generation techniques (4GT) Fourth generation techniques (4GT) The term fourth generation techniques (4GT) encompasses a broad array of software tools that have one thing in common. Each enables the software engineer to specify some

More information

Software Architectures. Lecture 4

Software Architectures. Lecture 4 Software Architectures Lecture 4 Roadmap of the course What is software architecture? Designing Software Architecture Requirements: quality attributes or qualities How to achieve requirements : tactics

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Object-Oriented Systems Analysis and Design

Object-Oriented Systems Analysis and Design Object-Oriented Systems Analysis and Design Noushin Ashrafi Professor of Information System University of Massachusetts-Boston Hessam Ashrafi Software Architect Pearson Education International CONTENTS

More information

Software Engineering Question Bank

Software Engineering Question Bank Software Engineering Question Bank 1) What is Software Development Life Cycle? (SDLC) System Development Life Cycle (SDLC) is the overall process of developing information systems through a multi-step

More information

An Enterprise Architecture and Data quality framework

An Enterprise Architecture and Data quality framework An Enterprise Architecture and quality framework Jerome Capirossi - NATEA-Consulting jerome@capirossi.org http://capirossi.org, Pascal Rabier La Mutuelle Generale prabier@lamutuellegeneral.fr Abstract:

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Agile Techniques for Object Databases

Agile Techniques for Object Databases db4o The Open Source Object Database Java and.net Agile Techniques for Object Databases By Scott Ambler 1 Modern software processes such as Rational Unified Process (RUP), Extreme Programming (XP), and

More information

6 Contracts and Scenarios in the Software Development Process

6 Contracts and Scenarios in the Software Development Process 6 Contracts and Scenarios in the Software Development Process Summary: Software development processes play an important role in the successful and timely delivery of software. There are different approaches

More information

Software Life-Cycle Management

Software Life-Cycle Management Ingo Arnold Department Computer Science University of Basel Theory Software Life-Cycle Management Architecture Styles Overview An Architecture Style expresses a fundamental structural organization schema

More information

Platform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture

Platform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture Platform Autonomous Custom Scalable Service using Service Oriented Cloud Computing Architecture 1 B. Kamala 2 B. Priya 3 J. M. Nandhini 1 2 3 ABSTRACT The global economic recession and the shrinking budget

More information