ICT Architectures 8 Software Architecture Bas Kruiswijk Leiden

ICT Architectures 8 – Software Architecture Bas Kruiswijk | Leiden March 19, 2019 1

Contents 1. Enterprise Architecture Viewpoints vs. Software Architecture Viewpoints 2. Key concepts of Software Architectures • Modularity • Integration 3. Other relevant concepts • Design Patterns • Model Driven Architecture 2

Roadmap Architecture Alignment Strategy • Strategic alignment • Information management • Enterprise architecture • Software architecture • Service oriented architecture • Business strategy • ICT Strategy 3

Three ‘types’ of ICT architectures Enterprise architecture Software architecture Service oriented architecture Conceptual foundations Enterprise scope Individual ICT system scope Focus on strategy and communication Focus on specification, design and realisation 4

Views and viewpoints Policy maker View pont View point Builder View point User Consistent model of the entire system 5

Archi. Mate 2 Viewpoints Fig. 7. 6 Classification of enterprise architecture viewpoints Table 7. 3 Viewpoint purpose Table 7. 4 Viewpoint abstraction levels 6

Archi. Mate 3 Viewpoints • Stakeholders and concerns - End user: For example, what are the consequences for his work and workplace? - Architect: What is the consequence for the maintainability of a system, with respect to corrective, preventive, and adaptive maintenance? - Upper-level management: How can we ensure our policies are followed in the development and operation of processes and systems? What is the impact of decisions (on personnel, finance, ICT, etc. )? - Operational manager: Responsible for exploitation or maintenance: For example, what new technologies are there to prepare for? Is there a need to adapt maintenance processes? What is the impact of changes to existing applications? How secure are my systems? - Project manager: Responsible for the development of new applications: What are the relevant domains and their relationships? What is the dependence of business processes on the applications to be built? What is their expected performance? - Developer: What are the modifications with respect to the current situation that need to be done? • Categories 1. Composition: Viewpoints that define internal compositions and aggregations of elements. 2. Support: Viewpoints where you are looking at elements that are supported by other elements. Typically from one layer and upwards to an above layer. 3. Cooperation: Towards peer elements which cooperate with each other. Typically across aspects. 4. Realization: Viewpoints where you are looking at elements that realize other elements. Typically from one layer and downwards to a below layer. 7

Archi. Mate 3 Viewpoints Category: Composition Name Perspective Organization Structure of the enterprise in terms of roles, departments, etc. Application Platform Shows structure of a typical application platform and how it relates to supporting technology. Information Structure Shows the structure of the information used in the enterprise. Technology Infrastructure and platforms underlying the enterprise’s information systems in terms of Single layer/ networks, devices, and system software. Multiple aspect Layered Provides overview of architecture(s). Physical environment and how this relates to IT infrastructure. Category: Support Name Perspective Product Shows the contents of products. Application Usage Relates applications to their use in, for example, business processes. Technology Usage Shows how technology is used by applications. Category: Cooperation Name Perspective Business Process Cooperation Shows the relationships between various business processes. Application Cooperation Shows application components and their mutual relationships. Category: Realization Name Perspective Service Realization Shows how services are realized by the requisite behavior. Implementation and Deployment Shows how applications are mapped onto the underlying technology. Scope Single layer/ Single aspect Multiple layer/ Multiple aspect Scope Multiple layer/ Multiple aspect Multiple layer/ Multiple aspect 8

Business Process Viewpoint Concepts and relationships Example 9

Application Structure Viewpoint Concepts and relationships Example 10

Application Usage Viewpoint Concepts and relationships Example 11

Focus of Archi. Mate as a language for Enterprise architecture • Any global structure within each domain - Main elements and their dependencies - Easy to understand for non-experts • Relevant relationships between the domains See fig. 5. 1 12

Viewpoints • Design viewpoints support architects and designers in the design process from initial sketch to detailed design. Table 7. 3 Viewpoint purpose • Views of the detailed level typically consider one layer and one aspect from the framework Table 7. 4 Viewpoint abstraction levels 13

The ‘ 4+1’ View model (Kruchten) • The “ 4+1 View”-model for Software Architecture - Describes four views, and a fifth view that shows how the four views work together (in a set of scripts; scenario’s) - Together describe the architecture of a software system - Every view models what is fundamental from the perspective of a particular stakeholder See 7. 1. 3. 1 14

The 4+1 Views • Logical view - Logical structure, the structural view of the system - Objects and their relationships • Development view - Shows how the objects (in the logical view) are combined to form software components or services • Process view - The runtime-components, the executables - The elements of the application to be implemented consists of • Physical view - The required hardware and other physical components needed to actuale run the application • The fifth view (the +1 -view) - Illustration of the actual functioning of the system from the perspective of the user / the intended use of the system 15

Architectural views in UML Class diagram Object diagram Design view Implementation view Component diagram Use case view Interaction diagram Statechart diagram Activity diagram Process view Deployment diagram 16

Software architecture and software engineering • Software engineering is about software quality (product and process quality) – how to design and implement good quality software? • So what is software quality? - Correctness, reliability, robustness - Performance - User friendliness - Verifiability - Maintainability - Reusability - Portability - Understandability - Interoperability - Productivity 17

Software engineering principles Top 3 (? ) • Separation of concerns - Due to inherent complexity of software system, make sure you can handle separate concerns separately (i. e. functionality and performance) • Modularity - Reduce complexity by dividing into smaller, self contained parts that can be designed, developed and deployed independantly - High cohesion and low coupling • Anticipation of change - Anticipate with design and implementation on likely changes 18

Modules and object orientation • Modules - Grouping of functionality and data - Modules as a higher level of abstraction and unit of reuse (which is limited) - Can be (more or less) separately realised and implemented • Object orientation - Programming-concept - Objects are a more direct representation of objects in the real world - Objects combine structure (the static aspect) and behaviour (the dynamic aspect) in one designconcept and programming model - Separation of interface and implementation 19

Object orientation Separation of interface and implementation fa c te r in ce rfa te in e Visable from the outside Description of functionality and how to use it ce fa fa te r r te in in ce implementation of the object Invisible from the outside (encapsulated) technical implementation 20

Components • Based on the concepts of object orientation • Focussed on the idea of building applications by assembling components • Components have, compared to objects, a few additional characteristics - Distributable (platform independant, middleware enabled) - Disconnectable at rum-time - Toolable (inspectable and usable by tools to assemble applications) 21

Services • From a technical perspective a logical next step following object- en component technology - Broad adoption of (internet)standards for web services - Platform independant - Central concept in (almost) alle current software development platforms (for instance the Java and. NET based platforms) • Services as the central business and technical concept - The service delivered to the user as the central concept, instead of software construction - Not only relevant to developer, but also to the user / business - Applications become less relevant – it is about services 22

Service Visible service interface description request Service interface response Service implementation Invisible, encapsulated internal implementation 23

Programming languages and modularity 5 th generation functioneel LISP Prolog 4 th generation abstract Oracle forms SQL 3 rd generation structured COBOL C C++ Java Visual Basic C# J 2 EE. Net 2 nd generation assembler 1 st generation machine Modular Object oriented Component based Service oriented 24

Monolithical and modular structure 25

Client/Server architecture Decentral Client Server Central 26

Distributed three-tier and n-tier architecture Presentation Process services Business logic Data Compound services Basic services Data 27

Application integration developments in perspective (1) shared databases 1: 1 Interfaces Application 1 Application 2 Client Server Generic facilities Usually bulk data exchange Corporate database Application 3 Application 4 specific generic 28

Application integration developments in perspective (2) Middleware (generic servicebus) Presentation Generic middleware Synchronous (services) Asynchronous (messages) Webservices (technology neutral) Presentation Technological or Organizational border Middleware Presentation Middleware Business logic Business logic Data Data Exchange of messages Based on XML and SOAP specific generic 29

Application integration developments in perspective (3) Portal for centralized access and authentication Portal Authentication, single sign-on Personalization look-and-feel Portal for integrated support for business processes Portal Authentication, single sign-on Personalization Presentation Orchestration Presentation Business logic Business logic Data Data specific generic 30

Design patterns • Introduced by “The gang of four”: Gamma, Helms, Johnson, Vlissides, in “Design Patterns, Elements of Reusable Object-Oriented Software” • Reusable templates for design problems • Experience and rules for “good” sofware architectures and design put into reusable patterns • Well documented - Goal, when to apply, high level (example) of design • Examples: - Separate presentation, interaction and business logic (model-view-controler or Observer pattern) - Encapsulate a set of interfaces (Facade pattern) 31

Model Driven Architecture • Architectural approach aimed at interoperability • Generation from model to implementation (Extreme Non. Programming) • Platform Independent Model - Modeling functionality and behaviour, without technological restrictions - Using generic middleware features - Adding extra details to facilitate the translation to the Platform Specific Model • Platform Specific Model - Application of a profile on the Platform Independent Model to perform a (highly automated) translation to a Platform Specific Model • Eventually generate working software out of the model Computation Independent Model mapping Platform Specific Model See 2. 2. 5 32

ICT Architectures 8 – Software Architecture 33