Technieken van de Software Architectuur, VUB ‘98-’99, Part 11 Technieken van de Software Architectuur Patrick Steyaert

Technieken van de Software Architectuur, VUB ‘98-’99, Part 12 Part 1: Introduction

Technieken van de Software Architectuur, VUB ‘98-’99, Part 13 Course Goal Teach techniques for designing, maintaining and reasoning about ‘complex’ software systems.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 14 ‘Programs’ 4Single purpose 4Single developer (or very small group) 4Short lived 4Single version 4Scalability is not an issue 4No openness to other systems Essentially the experience you have gained with ‘programming projects’.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 15 ‘Software Systems’ 4Multi purpose, or complex single purpose 4Long-lived 4Multiple versions, customizations 4Scalability is an issue 4Openness to other systems (e.g. legacy) Essentially what is experienced in ‘real-world’ software projects.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 16 Conventional Software Engineering Analysis Design Implementation Validation Verification Testing User RequirementsRunning System à top-down

Technieken van de Software Architectuur, VUB ‘98-’99, Part 17 Application of Conventional SE 4Rationale »discover problems early in the process »well-defined process (phases, milestones) 4But »too slow because of the ‘ceremony’ overhead »prone to communication errors »does not deal with change Works best in very mature domains.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 18 Non-functional Requirements [Buschmann&al.96] 4maintainability »how to deal with “aging”,... 4reusability »design for reuse,... 4adaptability »dealing with new requirements... 4testability 4interoperability “-ities” Conventional software engineering only deals with functional requirements !

Technieken van de Software Architectuur, VUB ‘98-’99, Part 19 Evolutionary Software Development [Brooks79] identify challenges prototype validate consolidate identify challenges à bottom-up prototype...

Technieken van de Software Architectuur, VUB ‘98-’99, Part 110 Application of the Evolutionary Software Development 4Rationale »small motivated teams »no ceremony overhead »the implementation of complex software contributes to its understanding (prototyping) 4BUT »does not necessarily scale up »weakly defined process »badly supported by tools, methods,... Works best in immature domains.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 111 Things that can go Wrong 4Lava flow dead code and forgotten design are frozen in 4Golden hammer when a hammer is the only tool I know how to use, then everything looks like a nail 4Input kludge software that fails straightforward tests 4Mushroom management requirements that are passed second hand through intermediaries

Technieken van de Software Architectuur, VUB ‘98-’99, Part 112 Things that can go Wrong (cont’d.) 4Version proliferation software that exists in a multitude of versions that are the result of copy-and paste programming 4Swiss army knife software that has excessive ‘whistle and bells’ 4Analisys paralysis trying to come up with ‘the perfect model’ 4Pet alligator phenomenon It’s cute while its small, but it keeps growing.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 113 The Challenge 4extremely complex systems 4multiple variations 4more than one mind can handle at once 4must manage complexity 4must manage variations 4must scale in time and size

Technieken van de Software Architectuur, VUB ‘98-’99, Part 114 Need for Software Models Testing Software Maintaining Extending Customizing Reusing Evolving Analyzing Documenting

Technieken van de Software Architectuur, VUB ‘98-’99, Part 115 Software Architecture 4A system is a set of communicating parts or components that fit together to realize a certain behaviour (i.e. to realize the behaviour requested by the functional requirements). 4A part or component is understood to be a systems building block that is defined by its external interface (like an ADT). 4A software architecture is a specification of a set of components and a communication pattern or protocol among them to achieve the behaviour. The architecture of a system is a high-level software model.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 116 Processes for Managing Complexity Problem decomposition: break big problems into smaller sub-problems that can be addressed relatively independently Solution composition: build big solution from small components

Technieken van de Software Architectuur, VUB ‘98-’99, Part 117 Separation of Concerns [AOP] natural decomposition »“the program looks like the design” »synergy among –problem structure –design concepts –implementation components »concerns are cleanly localized in both design and implementation »concerns are explicitly handled Separation of concerns is the primary process for managing complexity.

Technieken van de Software Architectuur, VUB ‘98-’99, Part 118 Typical Concerns 4recurring functional requirements »variations on functional requirements (e.g. recurring use cases with many similarities) 4cross-cutting features »e.g. permissions, on-line help 4recurring non-functional requirements »recurring technology changes (e.g. software that has to run on different platforms)

Technieken van de Software Architectuur, VUB ‘98-’99, Part 119 Conclusion 4Engineering ‘complex’ software systems requires new models and processes 4In this course we will teach models and processes to design, analyze, customize, reuse and evolve complex software systems

Technieken van de Software Architectuur, VUB ‘98-’99, Part 120 Course Overview (1) 4Part 1: Introduction + Recap of OO 4Part 2: Components and Framework Reuse 4Part 3: Evolutionary Software Design 4Part 4: Software Patterns

Technieken van de Software Architectuur, VUB ‘98-’99, Part 121 Course Overview (2) 4Part 5: Guest speakers (tentative list) »The Classification Browser (Koen De Hondt) »Reflective Architectures (Wolfgang De Meuter) »Metrics (Kurt Waeyenberg, EDS) »Genetic Programming Framework (Tom Lenaerts) »Domain Analysis (Frank Gielen, Alcatel) »Broadcast Software Factory (Wilfried Verachtert, MediaGeniX) »Repository Based Architecture (Michel Tilman, Unisys )

Technieken van de Software Architectuur, VUB ‘98-’99, Part 122 References 4[Brooks79]Brooks, F., P., The Mytical Man-Month, Addison-Wesley, Reading, MA, [AOP] Aspect Oriented Programming,