Technieken van de Software Architectuur, VUB ‘98-’99, Part 11 Technieken van de Software...
-
Upload
angelica-wickwire -
Category
Documents
-
view
222 -
download
0
Transcript of 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
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 2
Part 1: Introduction
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 3
Course Goal
Teach techniques for designing, maintaining and reasoning about ‘complex’ software systems.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 4
‘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’.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 5
‘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.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 6
Conventional Software Engineering
Analysis
Design
Implementation
Validation
Verification
Testing
User Requirements Running System
top-down
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 7
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.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 8
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 !
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 9
Evolutionary Software Development [Brooks79]
identifychallenges
prototype
validate
consolidate
identifychallenges
bottom-up
prototype
...
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 10
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.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 11
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
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 12
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.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 13
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
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 14
Need for Software Models
TestingSoftware
Maintaining
ExtendingCustomizing
Reusing
Evolving
Analyzing
Documenting
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 15
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.
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 16
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 1 17
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 1 18
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)
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 19
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
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 20
Course Overview (1)
Part 1: Introduction + Recap of OO
Part 2: Components and Framework Reuse
Part 3: Evolutionary Software Design
Part 4: Software Patterns
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 21
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 )
Technieken van de Software Architectuur, VUB ‘98-’99, Part 1 22
References
[Brooks79] Brooks, F., P., The Mytical Man-Month, Addison-Wesley, Reading, MA, 1979. [AOP] Aspect Oriented Programming, http://www.parc.xerox.com/aop