technieken van de software architectuur, vub ‘98-’99, part 11 technieken van de software...

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

Technieken van de Software Architectuur

Patrick Steyaert

[email protected]


Part 1: Introduction


Course Goal

Teach techniques for designing, maintaining and reasoning about ‘complex’ software systems.


‘Programs’

Single purpose Single developer (or very small group) Short lived Single version Scalability is not an issue No openness to other systems

Essentially the experience you have gained with ‘programming projects’.


‘Software Systems’

Multi purpose, or complex single purpose Long-lived Multiple versions, customizations Scalability is an issue Openness to other systems (e.g. legacy)

Essentially what is experienced in ‘real-world’ software projects.


Conventional Software Engineering

Analysis

Design

Implementation

Validation

Verification

Testing

User Requirements Running System

top-down


Application of Conventional SE

Rationale» discover problems early in the process» well-defined process (phases, milestones)

But» too slow because of the ‘ceremony’ overhead» prone to communication errors» does not deal with change

Works best in very mature domains.


Non-functional Requirements [Buschmann&al.96]

maintainability» how to deal with “aging”, ...

reusability» design for reuse, ...

adaptability» dealing with new requirements ...

testability interoperability

“-ities”

Conventional software engineering only deals with functional requirements !


Evolutionary Software Development [Brooks79]

identifychallenges

prototype

validate

consolidate

identifychallenges

bottom-up

prototype

...


Application of the Evolutionary Software Development

Rationale» small motivated teams» no ceremony overhead» the implementation of complex software contributes to

its understanding (prototyping)

BUT» does not necessarily scale up» weakly defined process» badly supported by tools, methods, ...

Works best in immature domains.


Things that can go Wrong

Lava flowdead code and forgotten design are frozen in

Golden hammerwhen a hammer is the only tool I know how to use, then

everything looks like a nail

Input kludgesoftware that fails straightforward tests

Mushroom managementrequirements that are passed second hand through

intermediaries


Things that can go Wrong (cont’d.)

Version proliferationsoftware that exists in a multitude of versions that are

the result of copy-and paste programming

Swiss army knifesoftware that has excessive ‘whistle and bells’

Analisys paralysistrying to come up with ‘the perfect model’

Pet alligator phenomenonIt’s cute while its small, but it keeps growing.


The Challenge

extremely complex systems multiple variations more than one mind can handle at once must manage complexity must manage variations must scale in time

and size


Need for Software Models

TestingSoftware

Maintaining

ExtendingCustomizing

Reusing

Evolving

Analyzing

Documenting


Software Architecture

A 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).

A part or component is understood to be a systems building block that is defined by its external interface (like an ADT).

A 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.


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


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.


Typical Concerns

recurring functional requirements» variations on functional requirements (e.g.

recurring use cases with many similarities)

cross-cutting features» e.g. permissions, on-line help

recurring non-functional requirements» recurring technology changes (e.g. software

that has to run on different platforms)


Conclusion

Engineering ‘complex’ software systems requires new models and processes

In this course we will teach models and processes to design, analyze, customize, reuse and evolve complex software systems


Course Overview (1)

Part 1: Introduction + Recap of OO

Part 2: Components and Framework Reuse

Part 3: Evolutionary Software Design

Part 4: Software Patterns


Course Overview (2)

Part 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 )


References

[Brooks79] Brooks, F., P., The Mytical Man-Month, Addison-Wesley, Reading, MA, 1979. [AOP] Aspect Oriented Programming, http://www.parc.xerox.com/aop

technieken van de software architectuur, vub ‘98-’99, part 11 technieken van de software...

Documents