1. CSCI 360: Software Architecture & Design
Instructor: Xenia Mountrouidou

2. Who am I? Dr. X – Computer Scientist
PhD at North Carolina State University – Optical networks performance
Worked at IBM – Software Performance Engineer
Post doc at College of William and Mary – research on performance and power savings for hard disk drives
Assistant professor at Jacksonville University, Wofford College
Assistant professor at CofC
Scuba diver, manga comics collector, science fiction reader, hacker

3. Who am I?

4. Objectives of the Lectures
Appreciate the Fundamentals of Software Engineering:
Methodologies
Process models
Description and modeling techniques
System analysis - Requirements engineering
System design
Implementation: Principles of system development

5. Outcomes After completing CSCI 360 students will be able to:
Judge legal issues in software projects
Construct UML diagrams
Apply UML diagrams in different phases of a software engineering project
Formulate the requirements and specifications for a software project
Examine software architectural styles
Apply appropriate design principles to software projects
Build software with OO Design principles

6. Outcomes Compare different software designs
Design and implement software test cases
Explain the software lifecycle and how it applies to different projects
Build GUIs for enhanced user experience
Understand the importance of project management in software
Distinguish software design patterns
Design software projects considering security, performance, usability, and data integrity.

7. Assumptions for this Class
You have taken CSCI 220, 230, …
Beneficial:
You have had practical experience with a small/medium software system
You have experienced major problems.

8. Motivation Why should you take Software Architecture and Design?
…. And why did you take CSCI 360?

9. Grading Criteria Comprehensive Exam 30% Project Quizzes Homework 10%
Total
100%

10. Syllabus You need to read it
Ignorance of the rules does not exempt you from them

11. Outline of Today’s Lecture
The development challenge
Dealing with change
Concepts: Abstraction, Modeling, Hierarchy
Methodologies
Organizational issues
Lecture schedule
Exercise schedule
Associated Project

12. Can you develop this system?

13. Can you develop this system?

14. Can you develop this system?

15. Can you develop this system?
The impossible
Fork
Can you build this? The question has, however, several possible answers. The first immediate answer might be no, because it is physically impossible. But we are engineers, let’s try. Let’s find out, if we can build it, and if not, what the problem is. Maybe we can fix the original problem specification.

16. Physical Model of the impossible Fork (Shigeo Fukuda)

17. Why is Software Development difficult?
The problem is usually ambiguous
The requirements are usually unclear and changing when they become clearer
The problem domain (called application domain) is complex, and so is the solution domain
The development process is difficult to manage
Software offers extreme flexibility
Software is a discrete system
Continuous systems have no hidden surprises
Discrete systems can have hidden surprises! (Parnas)
David Lorge Parnas - an early pioneer in
software engineering who developed the
concepts of modularity and information hiding
in systems which are the foundation of
object oriented methodologies.

18. Software Development is more than just Writing Code
It is problem solving
Understanding a problem
Proposing a solution and plan
Engineering a system based on the proposed solution using a good design
It is about dealing with complexity
Creating abstractions and models
Notations for abstractions
It is knowledge management
Elicitation, analysis, design, validation of the system and the solution process
It is rationale management
Making the design and development decisions explicit to all stakeholders involved.
Rubic Cube blindfolded
Rubic Cube in 6 seconds:
Rubic cube by a 3 year old,
2 Rubic Cubes at the same time:
3 Rubic Cubes in a row: p://

19. Can we not use the Scientific Method?
Not exactly, we need ideas and hypotheses
The scientific method, unfortunately, has never quite gotten around to saying exactly where to pick up these hypotheses.
The traditional scientific method has always been at the very best, hindsight
It's good for seeing where you've been. It's good for testing of what you think you know
But it can't tell you where you should to go
Creativity, originality, inventiveness, intuition, imagination – "unstuckness," in other words – are completely outside the domain of the scientific method
Robert Pirsig, Zen and the Art of Motorcycle Maintenance, p. 251, Bantam Books, 1984.

20. Techniques, Methodologies and Tools
Formal procedures for producing results using some well-defined notation
Methodologies:
Collection of techniques applied across software development and unified by a philosophical approach
Tools:
Instruments or automated systems to accomplish a technique
Interactive Development Environment (IDE)
Computer Aided Software Engineering (CASE)

21. Computer Science vs. Engineering
Computer Scientist
Assumes techniques and tools have to be developed.
Proves theorems about algorithms, designs languages, defines knowledge representation schemes
Has infinite time…
Engineer
Develops a solution for a problem formulated by a client
Uses computers & languages, techniques and tools
Software Engineer
Works in multiple application domains
Has only 3 months...
…while changes occurs in the problem formulation (requirements) and also in the available technology.

22. Software Engineering: A Working Definition
Software Engineering is a collection of techniques,
methodologies and tools that help with the
production of
A high quality software system developed with a given budget before a given deadline
while change occurs
Challenge: Dealing with complexity and change 20

23. Software Engineering: A Problem Solving Activity
Analysis:
Understand the nature of the problem and break the problem into pieces
Synthesis:
Put the pieces together into a large structure
For problem solving we use techniques, methodologies and tools.

24. Application of these Concepts in the Exercises
Course Outline
Dealing with Complexity
Notations (UML, OCL)
Requirements Engineering, Analysis and Design
OOSE, SA/SD, scenario-based design, formal specifications
Testing
Vertical and horizontal testing
Dealing with Change
Rationale Management
Knowledge Management
Patterns
Release Management
Configuration Management, Continuous Integration
Software Life Cycle
Linear models
Iterative models
Activity-vs Entity-based views
Application of these Concepts in the Exercises

25. Textbook Bernd Bruegge, Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns and Java, 3rd Edition
Publisher: Prentice Hall, Upper Saddle River, NJ, 2009;
ISBN-10:
ISBN-13:
Additional readings will be added during each lecture.

26. What to do next? Reading for the next two weeks
Chapter 1 and 2, Bruegge&Dutoit, Object-Oriented Software Engineering
Visit Oaks and course website
Start working on H1 and prepare for quiz next week!

27. Bibliography
Bernd Bruegge, Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns and Java, 3rd Edition