Nov. 15, 2013
cs561 Software Engineering

Last lecture
Cohesion
Coupling
Design principles

This time

More on Design Principles

Portablilty
	Simple - use a portable programming language
	Use one that is common
	Don't use assembly unless absolutely necessary (e.g. embedded systems)

Testability
	Automatic testing (UNIX redirection, JUnit, etc.)
	Manual (Debug print switch/common output)

Defensive design

	trying to ensure there aren't faults in code
	Use design by contract
		Preconditions
		Postconditions
		Invariants (don't change when a method executes)

		All are boolean expressions
		All can be expressed in a formal constraint language (e.g. OCL)

		Use assertions
			assert( some boolean expression )
			keyword in most languages
			if assertion is false program ends immediately

Techniques to make good design decisions
	Consider existing priorities and objectives for quality
	Consider memory and CPU efficiency
		maintainbaility, portability , usability
	
	List design decision alternatives
	list advantages and disadvantages of alternatives
	Does an alternative prevent you from meeting an objective
	Choose alternative that best meets objectives
	Adjust priorities as necessary

Cost-benefit analysis
	Want to reduce costs and increase benefits
	Often taught in management
	SW Eng Work
		maintenance for life of system
		cost of doing requirements, design, implementation, QA
		time measured in person days or person months
		cost = salary + office space + travel + other costs
	"Other" or incremental costs
		Development technology
		End-user support and product support personnel
		Time used/saved by doing proper design
	Benefits of increased sales

Model driven development
	Models should give a simplified view of the system
	Some modeling tools now generate code (UML has been around since the 
        90's)
		Visio
	Some tools now may generate all code for certain applications
		Hibernate
	Model is now a high level program
	Some development work can be exclusively within the model
	
	Some detailed algorithms must still be coded though
	
	May need a Platform Independent Model (PIM)
	Then may find need for several Platform Specific Models

Software architecture - like a building
	architect is in charge of project as a whole
	Architecture - process of designing system's global organization, 
        dividing it into subsystems, deciding how subsystems will interact, and 
        determining the interfaces

SW Architectural Model is _very_ important
	Core of system design - it is a blueprint
	
	Needed because:
	1. Helps everyone to understand the system
		Defines communication protocols
	2. Allows people to work in isolation on individual system parts
		Architecture must define how pieces will be put together 
                (interfaces)
	3. Allows for extension of the system
		Know what you are building - know how to leave openings to 
                build more on
	4. Allow for reuse and reusability

Good models have multiple views
	How system is broken into subsystems (package view)
	How components interact at runtime (activity diagrams)
	Data shared by subsystems (class diagrams and data dictionary)
	Components existing at runtime (component/deployment diagrams)

Model should be stable
	Add small components without breaking it

Model development

Step 1:
	Domain model/use cases
	Databases
	Components needed
Step 2:
	Refinement by identifying component interactions, interfaces between 
        them, data distribution and functionality, and any reusable components 
        from other systems
Step 3:
	Review use cases to ensure each is feasible in the architecture (return 
        to steps 1/2 if necessary)
	Finalize interfaces
Step 4:
	Finalize class diagrams and interaction diagrams
	
Can describe with UML model for packages
	Often refer to Java packages, but not always
	
	See package diagram (how to show import)
	
Component diagram
	Shows how system components are related to one another
	Lollipop symbol - shows interface between components
		Component could execute another component, generate another, 
                or communicate with another.
	Helps to show logical grouping of components
Deployment diagrams
	shows which components are on what hardware using 3D boxes
	Links between nodes show communication

Architectural patterns (styles)

Used for component design
All go for best use of design principles

Multi-layer
Client server
Broker
Transaction Processing
Pipe-and-Filter
Model-View-Controller
Message-Oriented

Multi-layer
	Related to layer cohesion (communication between layers goes only to 
        layers below it)
	Includes top-level UI - to allow for many UI's (admin, user, etc.)
	Next level is application functionality from use cases
	Bottom layer deals with data transmission and storage

	Ex. OS
		Lowest level is LL kernel for process creation, swapping, 
                scheduling
		Next is account management, display, etc
		Top is OS UI
	Also seen in communications systems

	Can add or replace layers

Client-Server
	One Client component
	One Server component
	Other models exist server communicating with client and DB
		Peer-to-peer