Software Engineering I
Notes for Nov. 20, 2013

In previous lectures, we discussed:

Design Metrics
Defensive design
Making good design decisions
Cost benefit analysis
Model driven development

This time we will discuss:

Software architecture
SW Arch. 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
	We should be able to 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
	These 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 Low Level 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

Broker Pattern

	Distribute aspects of software system transparently to other nodes

	Objects can call methods of another object without knowing where the other object is located
	Done via request from the broker

	CORBA - Common Object Request Broker Architecture used often for this

Transaction Processing Pattern

	A process reads a series of inputs one by one
	Each input describes a transaction
	Transaction dispatcher component decides what to do with the transaction
	Hands it to another component

	Often used in servers (e.g. flight reservations, banking, etc)
	Help to ensure atomicity

Pipe and Filter Pattern

	Stream of data in simple format is passed through a series of processes
	Series of processes is called a pipeline
	Data constantly fed into pipeline
	Processes work concurrently

	Example is speech transmission system

	Continuously read, process, compress, and transmit sound and regenerate at a remote
	location

Model View Controller
	Used to separate UI layer (the view and controller) from other parts of the system
	The functional layer or model is one component
	
	Model contains underlying classes whose instances may be viewed and manipulated
	View contains objects to render the appearance of data from the model in the UI
		Contains controls with which the user may interact
	Controller contains objects to control and handle the user's interaction with the view/model
		Contains logic that responds when the user types in data or clicks on buttons

	Swing GUI is based upon this
	Many dynamic webpages are based upon this
		Html/CSS - View
		JS/JSP - Controller
		Java - Model