CSCI 360: Software Architecture & Design Instructor: Xenia Mountrouidou

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

Who am I?

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

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

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.

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.

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

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

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

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

Can you develop this system?

Can you develop this system?

Can you develop this system?

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.

Physical Model of the impossible Fork (Shigeo Fukuda) http://of-ashes-and-wine.blogspot.com/2011/05/featured-artist-shigeo-fukuda.html https://www.google.com/search?q=Shigeo+Fukuda+impossible+fork&espv=2&biw=1425&bih=700&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj94oPG8sbOAhWFdx4KHU3mCZoQ_AUIBigB&dpr=1#imgrc=4-yPfiAuagUnuM%3A

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.

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 http://www.youtube.com/watch?v=JCkI2qh1SF4&NR=1 Rubic Cube in 6 seconds: http://www.youtube.com/watch?v=jI_zjWssn2g&feature=related Rubic cube by a 3 year old, 2 Rubic Cubes at the same time: http://www.youtube.com/watch?v=RW3akfdEGI8&feature=related 3 Rubic Cubes in a row: p://www.youtube.com/watch?v=api7yyAoAug&feature=channel

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, 20-20 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.

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)

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.

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

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.

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

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: 0136061257 ISBN-13: 978-0136061250 Additional readings will be added during each lecture.

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!

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