Software Architecture and Design CS 406 Software Engineering I Fall 2001

1. Software Architecture and DesignCS 406 Software Engineering IFall 2001 Aditya P. Mathur Purdue University Last update: September 25, 2001

2. Organization Part I: Design principles Part II: Design Patterns-I Part III: OO Design Part IV: Design Patterns-II Software Architecture and Design

3. Learning Objectives • To understand the basic principles of and techniques for software architecture and design. Software Architecture and Design

4. What is Architecture? • Organization of a software system • Components within the system. • Interfaces of the components and their interconnection. • Collaborations amongst components. • Involves the identification of those functional and non-functional requirements that have a significant impact on the system design. Examples: • Performance • Cost • Maintainability • Points of evolution Software Architecture and Design

5. What is Architecture? • Involves the identification of those functional and non-functional requirements that have a significant impact on the system design. Examples: • Performance • Cost • Maintainability • Points of evolution Software Architecture and Design

6. Architecture (2) • Analogy: Explain the architecture of: • Your favorite Concerto • Your favorite play • Your favorite home Software Architecture and Design

7. Architecture (3) • Software components-OO View: • Application • A subsystem • An object • A method • A data item Software Architecture and Design

8. Architecture (4) • Software components-Functional View: • Application • A Subsystem • A function • A data item • Do you understand the differences between a class, an object, and a function? Between a function and a method? Software Architecture and Design

9. What is Design? • As a process: The process by which the architecture of a software system is established. • As an artifact: The architecture of a software system describing system components and their interactions. Software Architecture and Design

10. Analysis and Design • Analysis: Focus on…. • Understanding, refining, and specifying requirements. • “What” are domain processes, concepts, terms, operations? • Design: Focus on…. • “How” can the requirements be met? Software Architecture and Design

11. Sync Artifacts Construct Analyze Refine Plan Design Test Design Phase Software Architecture and Design

12. Design Principles [1] • Design for change Change of algorithms Change of data representation Change of peripheral devices Change of underlying abstract machine Change of social environment Software Architecture and Design

13. Design Principles [2] • Separation of concerns Separation over time. Separation of quality attributes: e.g.performance and correctness Separation by views: e.g. data and control flows. Separation by parts of the system. Software Architecture and Design

14. Coupling (1) • Measure of interconnectedness. • Class C1 is coupled to class C2 if C1 requires C2 directly or indirectly. • Coupling measures the strength of dependence between classes and packages. Software Architecture and Design

15. Coupling (2) High coupling Low coupling Software Architecture and Design

16. Coupling (3) • Design with low coupling • A class that depends on 2 other classes has a lower coupling than a class that depends on 8 other classes. • Why low coupling?...Leads to easier changes, easier understanding, and easier re-use. Software Architecture and Design

17. Factors effecting coupling Software Architecture and Design

18. Cohesion (1) • Cohesion measures the strength of the relationship amongst elements of a class. • When methods within a class use a “similar” set of instance variables, the class is considered highly cohesive. Software Architecture and Design

19. Cohesion (2) • High cohesion and low coupling is preferred. (Example: Electric subsystem of a home.) • All operations and data within a class should naturally “belong” to the concept the class models. • Classes with high cohesion can often be described by a simple sentence. Software Architecture and Design

20. Types of cohesion • Coincidental : No meaningful relationship amongst elements of a class. May occur when a program is “modularized” by chopping it into pieces and making each piece a module. • Logical cohesion: Elements of a class perform one kind of a logical function, e.g. interfacing with the Point of Sale terminal hardware. • Temporal cohesion: All elements of a class are executed “together”. • Was NATO cohesive during its operations in the 90’s? Software Architecture and Design

21. Design Patterns [1] • A solution to a problem that occurs repeatedly in a variety of contexts. • Each pattern has a name. • Use of each pattern has consequences. Software Architecture and Design

22. Design Patterns [2] • Generally at a “higher level” of abstraction. • Not about designs such as linked lists or hash tables. • Generally descriptions of communicating objects and classes. Software Architecture and Design

23. Observer Pattern [1] • Need to separate presentational aspects with the data, i.e. separate views and data. • Classes defining application data and presentation can be reused. • Change in one view automatically reflected in other views. Also, change in the application data is reflected in all views. • Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified. Software Architecture and Design

24. Relative Percentages A B C D A X 15 35 35 15 D B Y 10 40 30 20 C Z 10 40 30 20 A B C D A=10% B=40% C=30% D=20% Application data Change notification Requests, modifications Observer Pattern [2] Software Architecture and Design

25. observers Observer Update() Subject For all x in observers{ x  Update(); } attach (Observer) detach (Observer) Notify () Concrete Observer Concrete Subject subject Update() GetState() SetState() observerState subjectState observerState= subject  getState(); Observer Pattern [3] Software Architecture and Design

26. :ConcreteSubject :ConcreteObserver-1 :ConcreteObserver-2 SetState() Notify() Update() GetState() Update() GetState() Class collaboration in Observer Software Architecture and Design

27. Abstract class defining the Observer interface. Note the support for multiple subjects. Observer Pattern: Observer code class Subject; class observer { public: virtual ~observer; virtual void Update (Subject* theChangedSubject)=0; protected: observer (); }; Software Architecture and Design

28. Abstract class defining the Subject interface. Observer Pattern: Subject Code [1] class Subject { public: virtual ~Subject; virtual void Attach (observer*); virtual void Detach (observer*) ; virtual void Notify(); protected: Subject (); private: List <Observer*> *_observers; }; Software Architecture and Design

29. Observer Pattern: Subject Code [2] void Subject :: Attach (Observer* o){ _observers -> Append(o); } void Subject :: Detach (Observer* o){ _observers -> Remove(o); } void Subject :: Notify (){ ListIterator<Observer*> iter(_observers); for ( iter.First(); !iter.IsDone(); iter.Next()) { iter.CurrentItem() -> Update(this); } } Software Architecture and Design

30. Observer Pattern: A Concrete Subject [1] class ClockTimer : public Subject { public: ClockTimer(); virtual int GetHour(); virtual int GetMinutes(); virtual int GetSecond(); void Tick (); } Software Architecture and Design

31. Observer Pattern: A Concrete Subject [2] ClockTimer :: Tick { // Update internal time keeping state. // gets called on regular intervals by an internal timer. Notify(); } Software Architecture and Design

32. Override Observer operation. Override Widget operation. Observer Pattern: A Concrete Observer [1] class DigitalClock: public Widget, public Observer { public: DigitalClock(ClockTimer*); virtual ~DigitalClock(); virtual void Update(Subject*); virtual void Draw(); private: ClockTimer* _subject; } Software Architecture and Design

33. Observer Pattern: A Concrete Observer [2] DigitalClock ::DigitalClock (ClockTimer* s) { _subject = s; _subjectAttach(this); } DigitalClock ::~DigitalClock() { _subject->Detach(this); } Software Architecture and Design

34. Check if this is the clock’s subject. Observer Pattern: A Concrete Observer [3] void DigitalClock ::Update (subject* theChangedSubject ) { If (theChangedSubject == _subject) { Draw(); } } void DigitalClock ::Draw () { int hour = _subject->GetHour(); int minute = _subject->GeMinute(); // etc. // Code for drawing the digital clock. } Software Architecture and Design

35. Observer Pattern: Main (skeleton) ClockTimer* timer = new ClockTimer; DigitalClock* digitalClock = new DigitalClock (timer); Software Architecture and Design

36. When to use the Observer Pattern? • When an abstraction has two aspects: one dependent on the other. Encapsulating these aspects in separate objects allows one to vary and reusethem independently. • When a change to one object requires changing others and the number of objects to be changed is not known. • When an object should be able to notify others without knowing who they are. Avoid tight coupling between objects. Software Architecture and Design

37. Observer Pattern: Consequences • Abstract coupling between subject and observer. Subject has no knowledge of concrete observer classes. (What design principle is used?) • Support for broadcast communication. A subject need not specify the receivers; all interested objects receive the notification. • Unexpected updates: Observers need not be concerned about when then updates are to occur. They are not concerned about each other’s presence. In some cases this may lead to unwanted updates. Software Architecture and Design

38. Summary • What is design? 2. What is architecture? 3. Where does design fit in a development process? 4. What are the general principles of design ? Reference for the Observer Pattern: Design patterns by Gamma et al., 1995, Chapter 5, Or read pp. 372-380 from Larman’s book or section 3.2.2.1 of Braude’s book. Software Architecture and Design