1. Software Architecture and Design BITS C461/IS C341 Software Engineering First Semester 2003-2004 Aditya P. Mathur Department of Computer Science Purdue University Last update: September 2, 2003

2. September 3, 2003Software Architecture and Design2 Organization Part I: Design principles Part II:Design Patterns-I Part III:OO Design Part IV:Design Patterns-II

3. September 3, 2003Software Architecture and Design3 Learning Objectives To understand the basic principles of and techniques for software architecture and design.

4. September 3, 2003Software Architecture and Design4 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

5. September 3, 2003Software Architecture and Design5 Architecture [2] Analogy: Describe the architecture of: Your favorite Concerto or a Carnatik Kriti Your favorite play Your favorite home

6. September 3, 2003Software Architecture and Design6 Architecture [3] Software components-OO View: Application (System) A subsystem An object A method A data item

7. September 3, 2003Software Architecture and Design7 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?

8. September 3, 2003Software Architecture and Design8 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.

9. September 3, 2003Software Architecture and Design9 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?

10. September 3, 2003Software Architecture and Design10 Design Phase Refine Plan Sync Artifacts AnalyzeDesignConstructTest

11. September 3, 2003Software Architecture and Design11 Design Principles [1] Design for change Change of algorithms Change of data representation Change of underlying abstract machine Change of peripheral devices Change of social environment

12. September 3, 2003Software Architecture and Design12 Design Principles [2] Separation of concerns Separation over time. Separation of quality attributes: e.g. performance and correctness Separation by parts of the system. Separation by views: e.g. data and control flows.

13. September 3, 2003Software Architecture and Design13 Coupling [1] Class C1 is coupled to class C2 if C1 requires C2 directly or indirectly. Coupling measures the strength of dependence between classes and packages. Measure of interconnectedness.

14. September 3, 2003Software Architecture and Design14 Coupling [2] High couplingLow coupling

15. September 3, 2003Software Architecture and Design15 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.

16. September 3, 2003Software Architecture and Design16 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.

17. September 3, 2003Software Architecture and Design17 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.

18. September 3, 2003Software Architecture and Design18 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”.

19. September 3, 2003Software Architecture and Design19 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.

20. September 3, 2003Software Architecture and Design20 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.

21. September 3, 2003Software Architecture and Design21 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.

22. September 3, 2003Software Architecture and Design22 Observer Pattern [2] A=10% B=40% C=30% D=20% Application data A B C D ADCB Relative Percentages Y10 40 30 20 X15 35 35 15 Z10 40 30 20 A B C D Change notification Requests, modifications

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

24. September 3, 2003Software Architecture and Design24 Class collaboration in Observer : ConcreteSubject :ConcreteObserver-1:ConcreteObserver-2 GetState() Notify() Update() SetState() GetState() Update()

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

26. September 3, 2003Software Architecture and Design26 Observer Pattern: Subject Code [1] class Subject { public: virtual ~Subject; protected: Subject (); virtual void Attach (observer*); virtual void Detach (observer*) ; virtual void Notify(); private: List *_observers; }; Abstract class defining the Subject interface.

27. September 3, 2003Software Architecture and Design27 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 iter(_observers); } for ( iter.First(); !iter.IsDone(); iter.Next()) { iter.CurrentItem() -> Update(this); }

28. September 3, 2003Software Architecture and Design28 Observer Pattern: A Concrete Subject [1] class ClockTimer : public Subject { public: virtual int GetHour(); } virtual int GetMinutes(); virtual int GetSecond(); ClockTimer(); void Tick ();

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

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

31. September 3, 2003Software Architecture and Design31 Observer Pattern: A Concrete Observer [2] DigitalClock ::DigitalClock (ClockTimer* s) { _subject = s; } _subject  Attach(this); DigitalClock ::~DigitalClock() { _subject->Detach(this); }

32. September 3, 2003Software Architecture and Design32 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. Check if this is the clock’s subject. // Code for drawing the digital clock.

33. September 3, 2003Software Architecture and Design33 Observer Pattern: Main (skeleton) ClockTimer* timer = new ClockTimer; DigitalClock* digitalClock = new DigitalClock (timer);

34. September 3, 2003Software Architecture and Design34 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 reuse them 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.

35. September 3, 2003Software Architecture and Design35 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.

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