System Engineering and Databases

1. System Engineering and Databases Lecture 2: Introduction to Software Analysis and Design Prof. Kazimierz Subieta Polish-Japanese Institute of Information Technology Institute of Computer Science, Warsaw, Poland subieta@ipipan.waw.pl http://www.ipipan.waw.pl/~subieta

2. Content • Boehm’s spiral model • Benefits and disadvantages of an iterative approach • Compromise: RUP model • The importance of models • Modelling software • Key concept - Architecture • The RUP 4+1 view model of architecture • Key concept - Components • Components and Architecture Acknowledgment: The material has been compiled from many Internet sources. It has no commercial purpose. Special thanks to Owen Johnson and anonymous authors of Rational Software Corporation, who were the original authors of many of the presented slides.

3. Boehm’s Spiral Model (1988) AN ITERATIVE AND INCREMENTAL PROCESS

4. Good Theory, who’s using it? Microsoft • Microsoft products like Excel or Word • can have several million lines of code. • Require hundreds of people to build and test. • Microsoft’s philosophy for product development has been to cultivate its roots as a highly flexible company. • Avoid structured software engineering practices. • Synchronise and Stabilise • This approach builds systems and features fast. • Is inherently bug-ridden • This is an excellent example of Boehm’s Spiral Model in practice.

5. Benefits of an Iterative Approach 1.Serious misunderstandings are made evident early in the lifecycle, when it’s possible to react to them. 2.It enables and encourages user feedback so as to elicit the system’s real requirements. 3.The team is forced to focus on the issues that are most critical to the project first. 4.Continuous, iterative testing enables an objective assessment of the projects status. 5.Inconsistencies between requirements, designs and implementations are detected early. 6.The workload of the team (even the testing team) is spread more evenly throughout the project life cycle. 7.The team can learn lessons and improve as they learn. 8. Stakeholders are given concrete evidence of the projects status throughout.

6. Disadvantages 1. Bugs and errors are recognised as unavoidable. 2.Not appropriate for safety critical systems. 3.Stakeholders like to know how much it will cost and when they can have it. • Even if the costs and deadlines are wrong. • Iterative approaches may be A BIT TOO HONEST for comfort. • It recognises risk, errors and the possibility of failure. • So many people still prefer the Ostrich attitude to risk

7. Compromise The Rational Unified Process -is an iterative approach -but it also recognises the value of small sequential processes Here’s a picture…

8. Compromise

9. The Rational Unified Process

10. Analysis and Design Analysis include the following activities: Recognition, explanation, modeling, specification, documentation of the business reality that future information system has to deal with; Determining the context of the project; Determining user requirements; Determining organizational and system requirements Other issues: hardware preferences, software tools, financial and time constraints, etc. The objective of analysis is recognition all the aspects of the business, which could influence the goal, organization or results of the project. The design phase is based on the results of analysis. It deals with many implementation issues related to data structures, processing algorithms, user interfaces, overall system architecture.

11. Real Life ModelsI • A Physical Model • any view you like! • The concept of Views • UML diagrams are 2 Dimensional • Software is complex and “multi-dimensional”

12. Real Life ModelsII • Abstraction – SHOWS roads and buildings HIDES the colour of buildings • Models are an Abstraction of reality • Abstraction depends on the perspective of the viewer • The model builder chooses what information • they consider relevant and want to communicate.

13. Models are an Abstraction of Reality Abstraction is relative to the viewer…

14. The Importance of Models • A large part of the Rational Unified Process focuses on building Models. • We use models to help understand the problem and • Shape the solution • “A model is a simplification of reality that helps us master a large complex system that cannot be comprehended easily in its entirety.” – Krutchen 2000 • “The choice of models and the choice of techniques used to express them will have a profound effect on the way that we think about the problem and shape the solution.” • If we get the model right • Our chances of getting the problem/ solution right is much higher.

15. Modelling Software • Software is too complex for any single two dimensional model to portray. • “There are no more small systems left to build”. Krutchen (2000)   • Attempts to Model Complexity • Fails to convey everything to everyone • Fails to follow modelling standards

16. The Solution for Engineering • For engineers building a building or a bridge then there’s an easy answer to complexity. They use Architectural plans or blueprints. • The solution to Engineering complexity is: 1)Agreed standards and notation for drawing 2)Blueprints for different uses • High level and detail levels • Different views – plan, elevation etc. • Different users – electrical, plumbing, furniture 3) Computer Assisted Design – C.A.D.

17. The Solution • The Solution to modelling software complexity is 1) Commonly understood diagram standards - aka modelling language UML 2) Multiple views on the model - Requirements - Logical - Deployment etc. • 3)CASE - Computer Aided Software Engineering • - make the drawing easier and • - maintain the integrity between multiple views of the same model.

18. Key Concept - Architecture • Rational Unified Process • is centred on the notion of Architecture i.e. systems architecture of software architecture • The main focus of the early iterations of the RUP are to • Produce and validate the software architecture By building an executable architectural prototype This evolves in later iterations into the full system • The reason for this is to • ATTACK RISK – “If you do not actively attack the risks in your project then they will actively attack you”

19. Architecture? • The RUP defines architecture as “the set of significant decisions about… • the organisation of the software system • the structural elements (and their interfaces) which make up the system and their behaviour in terms of how they work together. • The composition of these elements into progressively larger systems • The architectural “style” • Architecture is a brief description of the essential characteristics of the system Key word – description – i.e. text and/ or diagrams • In the worst case - “Architecture may take the form of an un-maintainable document of a few diagrams made up of boxes and arrows reflecting imprecise semantics that could only be interpreted by its authors”. Krutchen (2000)

20. What should software architecture describe? • It should cover • Structure • Behaviour • Usage • Functionality • Performance • Resilience • Reuse • Economic and Technical constraints and trade-offs • Aesthetics • AT A HIGH LEVEL OF ABSTRACTION

21. How do we describe architecture? • Answer – In our Model • At it’s simplest – architecture is a high level abstraction of the essential elements in our model. • The model we start to build using UML is a superset of the architecture. • Models are complete representations of the system DESIGN • Architectures are the ‘architecturally significant’ elements. • Architecture • “architecturally significant” if important for understanding the system. • The main question to answer at this stage is how do we represent the architecture Or the full design model for that matter.

22. The 4+1 View Model of Architecture • The RUP suggests a five view model for describing a systems architecture.

23. Developing an architecture that works • The Rational Unified Process provides • A methodical, systematic way to • Design, develop and validate an architecture. • Templates for describing an architecture based on the 4+1 views • Guidelines for how to make architectural choices

24. Key Concept - Components Payment System • Components are drawn in UML as: • A Software Component can be defined as “a non-trivial piece of software, a module, a package or a subsystem that fulfils a clear function, has a clear boundary and can be integrated into a well defined architecture.” • Key words – non trivial • Clear function • Clear boundary

25. Components and Architecture • Modular Architectures are based on well formed components • You identify, isolate, design, develop and test components • You test them individually first then integrate gradually to form the whole system. • Components can/ should be designed to be re-usable • Especially where they solve common problems • Better than just utilities and class libraries • Organisations build up their set of re-usable components • Component can be bought rather than built • Development stops being writing programs and becomes – • Finding, Integrating and Testing Components