Software Engineering Design Resolution

1. Software Engineering Design Resolution Chapter 8

2. Software Engineering Design Resolution software engineering design • Goalof developing a Design Resolution is to develop a design of the solution to the problem stated in the requirements. • The Design Resolution consists of 2 main parts • Architectural Design • Detailed Design • The result of design resolution is recorded in the design document from which code implementation can be performed. SRS Design Analysis Design Resolution: - Architectural - Detailed Design Doc

3. Design Resolution (the Design) • At the end of Design Analysis, we have looked at the requirements and the “System” mainly as a black box in terms of the external behavior and external characteristics – although we have started to get into “potential” internals with Class Diagrams. • Designing is composed of two levels: A) Architectural: where the following are defined or “opened” • major components, • their responsibilities, properties, interfaces • their high levelstructure (relationships and interactions) among components B) Detailed: where the following are defined and “opened” • internal elementsof the major components, • their processing algorithms and attribute structure (data structure) • those elements’ structures, relationships among element, and interactions among elements,

4. Main Parts of Software Architecture • Decomposition (or Composition) of “main”components • Assignment of responsibilities (functionalities)to the maincomponents • Specification of propertiesof the main components { Specification of the states and transitions of states of the main components (note that state is a property) } • Specification of relationshipsamong components • Specification of collaboration among components (note that collaboration is a kind of a relationship) • Specification ofinterfaces among components may go back & modify

5. The Role of “Decomposition” in Design “Requirements,” “Use Cases, “ “Conceptual Model” Water Heating System (Caldera) level 0 Decomposition User Interface Heating Control level 1 Water Heater Controller Thermostat Interface Timer Interface level 2

6. A Decomposition - Pictorial Discussion(closer to “Application” Domain Driven Arch.) Acct. Rec. Acct. Pay. Financial System Gen. Ledger - Decomposedinto main parts by “Responsibilities” - What other criteria may be used for decomposing into parts? Acct-Pay Post data Gen_Ledger Post data Acct-Rec. Identifying relationships We still need to specify interfaces among the components and key properties

7. Another Decomposition - Pictorial Discussion(closer to “Software” Domain Driven Arch.) UI Financial Logic DB Financial System Process/Control (messages, interrupts, etc.)

8. ArchitecturalDesign Considerations-DeSCRIPTR • DeSCRIPTR • **Decomposed system into major components ** • DeSCRIPTR • States that the major components may exist in • DeSCRIPTR • Collaboration among components to achieve a goal • DeSCRIPTR • **Relationships among the major components in terms of dependencies and communications ** • DeSCRIPTR • ** Interfaces among the components that have relationships ** • DeSCRIPTR • **Properties that the major components must possess or satisfy ** • DeSCRIPTR • Transitions of components’ states • DeSCRIPTR • ** Responsibilities of the major components ** An Architectural Design document may contain all or parts of this list. Should have the** items.

9. DetailedDesign Considerations • Detailed Design is a further refinementof the Architecture Design, starting with detailed decomposition of major components and all the subsequent refinements associated with smaller elements. Thus a refined DeSCRIPTR is part of the detailed design. • There are 4 more considerations in Detailed Design: (PAID) • Packaging of the components and related element • Algorithms that need to used to implement the services/functionalities • Implementation specifications for the packaged components, including language specific concerns • Data structures and data types needed for the implementation A bit early?

10. ***Are There Design Principles( Guidelines)?*** Design Principles User Oriented Constructive Design “Criteria” Basic Aesthetic Feasible Economical Implementability Modularity Adequate Changeable delight simple reusable small least privilege reuse Improve & extend experience “Beauty” in design (simple & powerful) Info hiding coupling cohesion

11. Some “Basic”Design Principles • Design Principles help make the design better. Some are the same as other disciplines and some are specific to software engineering. The “Basic” Design Principles are meant to “improve satisfying product specification” (more general): • Feasibility • The proposed design can betechnically implemented, thus realizable • Adequacy • The proposed design meets the stakeholders needs and expectations (note: expectations are sometimes desires) • Economy • The proposed design can be implemented within reasonable cost (people resource and tool resources) and reasonable schedule. • Changeability (harder to evaluate) • The proposed design results in implemented system that is “easily”modifiable (for both functional maintenance and quality maintenance.)

12. Some Observations about Basic Principles • Most of the Basic Principles are not easy to assess: • Feasibility : even though this can end up in a binary yes/no answer, it may take a while to assess. (Often, we choose the easy way out and design what we know works.) • Adequacy: This may not be a binary answer, but a sliding scale answer in the form of “degree” of adequacy. • Number of requirements implemented / total requirements • Any other potential metric? • Economy : Some parts of this may be easy to assess and others more difficult. • Effort needed – person months • Elapsed time – calendar days or months • Cost – dollars expended • Risk - ?? • Changeability: how would you gauge this? • Modular size? • Amount of documentation and type of documentation? • Existence of external interfaces and parameterized interfaces ? • Usage “abstract” Classes and inheritance Does this lead us to design: a) only “doable” things ? b) “cheapest” things that are “barely adequate” c) lots of small functionalities that can be modified

13. Back to “Solitaire System” • Design a Software System which will allow the user to play the card game Klondike Solitaire. This software should be accessible on the web. It should be able to demonstrate the following attributes: • The complete game board must be visually in one window, showing the components of the game (the tableau – the 7 table piles, the deck pile, the discard pile, the suit piles) • There will be additional information available about the game as defined in a menu of options. This should include minimally, Start Game, Pause Game, Quit Game, Resume Game. It may include other information such as player name, timing information, and score. • The cards must be created, shuffled, and dealt when Start Game is selected. The game must have an appealing GUI. The game must follow the standard rules for the physical Klondike game. • Think about the high level design in terms of DeSCRIPTR : first - - - what are the • main component ------- etc. ? • With just the main components --- before you go further think about the 4 Basic • principles of Feasibility, Adequacy, Economy, Changeability Now --- Does this approach affect your thinking and Designing ?

14. Constructive-Design“Criteria” • Constructive (Construction) Design Principles are design criteria that experience has shown to lead to “good quality” software products that also satisfy the Basic Design Principles: • Modularity Principles: • Self contained modules (via info hiding, least privilege, high cohesion and low coupling) with well defined interfaces lead to high quality product • Implementability Principles: • Designs that are “easier” to implement(simple/reuse) lead to high quality product • Aesthetic Principles (of internal design): • “beauty” and “ease of use” are concerns that lead to designs that please other designers/implementers ---- and users Note that these principles are nice but still not clear – “measurable?”

15. Modularity in Design • Construct(via decomposition and reconstruction) the design in the form of well-defined “modules,” which are independent(self- contained) units that 1) perform specific services and 2) have clear interfaces. • The definition of a module is not clear: (module may be a Class) • Is it size oriented (number of parts or lines of code)? • Is it complexity oriented (relations and dependencies)? • Advantages of “clearly-defined” (less size and complexity?) modular design : ( “easier”≡ takes less effort ? ) • Easier to understand and explain to others • Easier to document • Easier to change • Easier to test and debug • Easier to re-use • Easier to improve upon for performance and other properties

16. Modularity Principles • 3 sub-principles (for Modularity) are design guides: • Principle of “Small” Modules: Design with Smaller Modules is Better • Physical size based (small number of LOC or parts) • Mental states based (small number of binary decisions) • Principle of Information Hiding: Design that Shields Internal Details of a Module’s Structure and Processing is Better • Shield the internal structure and processing • Must have clearly defined interfaces that do not expose the module’s internals • Principle of Least Privilege: Design that Does not Allow Access to Unneeded Resources is better • Restrict the modules from accessing unneeded resources • A bit related to coupling (next slide) Which of the above would you emphasize as a software engineer if you are asked to ensure software security? ---- why?

17. Information Hiding Example Similar to Text (p238) Employee Employee name address birthDate . . getAge( ) name address age . . getAge( ) (b) (a) If we want to get the age of the person, it would be nice to just evoke getAge( ) and have the age returned regardless of how the attributes of the person are set. So, we may “hide” the existence of “age” or “birthdate” attribute of Employee. We can also make the attribute “private” to bring in the principle of “least privilege” i) getAge is easy in case (a), but ---- age needs to be “updated” annually ii) getAge may require a computation of [currentdate – birthdate] in (b) however ---- we may need birthdate for other reason where age won’t suffice

18. Low Coupling and High Cohesion • Coupling is the degree of connectednessamongmodules: • Control passing • Data passing • Coupling should be kept to minimum – strive for low coupling in design • Cohesion is the degree of relatedness of the parts withina module • Cohesion should be maximized – strive for high cohesion in design

19. Levels of Coupling • Content coupling (worst – high coupling) • One module directly references the content of another module; (such as using a pointer to get to another module’s data and modifying that data.) • Common coupling • Two or more modules all use a common, “global” data. • Usage of a database as a common “blackboard” for some control purpose. (This one is used very heavily in commercial applications.) • Control coupling • One module passes information or a parameter to control the logic of another module. (This one is often done in our design.) • Stamp coupling • One module passing a complete structure to another, through parameter, even though only a small part of the data structure is needed. (Passing a complete employee record when only the birth-date field is required. This also happens often in lazy design.) • Data coupling (best – low coupling) • Only the necessary items are passed from one module to another.

20. “Levels” of Cohesion • Coincidental cohesion (worst – weakest) • A module that performs multiple, unrelated tasks. • Logical cohesion • A module that performs a “series of related” functionalities. (This is often done in commercial world where a module performs the insertion, deletion, and modification of records of a “master-file”) • Temporal cohesion • A module that performs a set of tasks that are related in time (temporal). (This is also often done in commercial world where all the databases are “opened” at once during the beginning of a module.) • Procedural cohesion • A module that performs two related procedures that probably should be doneseparately (such as read a record from one file and based on the information go update another file.) • Communicational cohesion • A module performing a sequence of related tasks on the same piece of data where the sequence of tasks is based on some specific procedure. • Sequential cohesion • A module performing related sequence of tasks where an output of one is the input to the next task in sequence. • Functional cohesion (best – strongest) • A module that performs exactly one task to achieve a single goal.

21. An Excursion Into OO Class Cohesion class_a class_b x y z w x y z w Method_xx( ) Method_yy( ) Method_zz( ) Method_xx( ) Method_yy( ) Method_zz( ) There is not enough information to allow us to tell which class is more cohesive. So --- we need to look at more details: - how are the attributes used by the methods? - how do the methods interact, if any?

22. An Excursion Into OO Class Cohesion class_a class_b x y z w x y z w Method_xx( ) Method_yy( ) Method_zz( ) Method_xx( ) Method_yy( ) Method_zz( ) Method_xx uses x, y, z Method_yy uses y, z Method_zz uses z, w Method_xx uses x, y Method_yy uses y, w Method_zz uses z Since class_a’s methods more commonly access the attributes, class_a may be more cohesive. Let’s look at some metrics of class cohesion -----

23. An Excursion Into OO Class Cohesion (cont.) • There are several ways to “measure” Class cohesion • These 2 deal with how the attributes are “commonly” used by the methods: • LCOM (Lack of Cohesion) by Chidamber and Kemerer LCOM = ( #P - # Q ) - where #P is the cardinality of the set of pairs of methods that have no common instance variables, and #Q is the cardinality of the set of pairs of methods that have common instance variables - if #P ≤ #Q, then LCOM = 0 • LCOM5 by Henderson-sellers ( a variant) LCOM5 = [1 – ((∑Uai) / (m * A)) ] - where ∑Uai is the number of methods that access each attribute ai, summed over all the ai’s, - m is the total number of methods in the class - A is the total number of ai’s Note that the larger the LCOM is, the less is the Class cohesion.

24. An Excursion Into OO Class Cohesion LCOM = (#P - #Q) - There are 3!/[2!(3-2)!] = 3 pairs of methods or { (xx, yy), (yy,zz), (xx,zz) } - #Q = cardinality of pairs that have common attribute = 3 - #P = 0 - if #P ≤ #Q, then LCOM = 0 Thus LCOM = 0; this is good because the bigger LCOM is the less cohesive is the class. LCOM5 = [1 - ((∑Uai) / (m * A)) ] - ∑Uai= 1 + 2 + 3 + 1 = 7 - m = sum of methods = 3 - A = sum of attributes = 4 LCOM5 = [ 1 – (7/12) ] = 5/12; this is also good because the closer LCOM5 is to 1, the less cohesive is the class Class_a x y z w Method_xx( ) Method_yy( ) Method_zz( ) Method_xx uses x, y, z Method_yy uses y, z Method_zz uses z, w

25. An Excursion Into OO Class Cohesion LCOM = (#P - #Q) - There are 3!/[2!(3-2)!] = 3 pairs of methods or { (xx, yy), (yy,zz), (xx,zz) } - #Q = cardinality of pairs that have common attributes = 1 - #P = 2 LCOM = 2 – 1 = 1 ; this is bigger and thus worse than Class_a LCOM5 = [1 - ((∑Uai) / (m * A)) ] - ∑Uai= 1+ 2 + 1 + 1= 5 - m = sum of methods = 3 - A = sum of attributes = 4 LCOM5 = [ 1 – (5/12) ] = 7/12; this is larger and thus worse than Class_a Class_b x y z w Method_xx( ) Method_yy( ) Method_zz( ) Method_xx uses x, y Method_yy uses y, w Method_zz uses z

26. Balancing the Design • Balance low coupling and high • cohesion in design by thinking • of : • Easier to understand & explain • Easier to document • Easier to change • Easier to test and debug • Easier to re-use • Easier to improve upon • Design small, single purpose, cohesive modules --- sounds good • Butif the whole design is composed of these, then there may be a lot of passing of control and/or data among these in order to accomplish anything significant ---- causing high coupling. • So we need to constantly balance between low couplingand high cohesion. These two criteria may sometimes collide against each other.

27. Implementability Principles • Once we have an implementable design, it is still important to address how easy is it to implement: • “Simpler” design are easier to understand and implement (e.g. simple in # number of steps?) • Reuse the existing artifacts to save effort and time • Design with reuse for the future. Design with reuse often introduces more work and possibly even more complexity. --- why? Again, design is a balancing act here, too. Design for reuse may conflict with design for only the specific and simple solution.

28. Aesthetic (Design) Principles • A design is better because it is more “pleasing to the mind” (or beautiful). • Gelernter of Yale states that beauty is: • Simplicity • Yet powerful (more functionalities and speed) Simple and powerful is hard to measure and is still new. However, many Mathematical proofs have been labeled “elegant” because they are simple and powerful ---- “innovative?”

29. Other Principles • User Oriented Design: • Design to “delight” the users • Matches or exceeds user expectations • Stays within users’knowledge and experience context • Design to “improve the user experience” • matches users’ past experience and extends the experience by extrapolating and improving some part of the interaction These are just as hard to measure and define as the aesthetic principles. Yet, Steve Jobs of Apple seem to introduce new products that capture this concept.

30. Summarizing Design Principles Design Principles Construction Design “Criteria” User Oriented Basic Aesthetic Economical Feasible Implementability Modularity Adequate Changeable delight simple reusable small least privilege reuse Improve & extend experience Info hiding beauty (simple & power) coupling cohesion