1 Essential Software Architecture Documenting a Software Architecture.

Slides:



Advertisements
Similar presentations
Deliverable #8: Detailed Design - Overview due: Wednesday, 7 March All Deliverable materials are to be posted into Team Concert. Your to.
Advertisements

Kellan Hilscher. Definition Different perspectives on the components, behavioral specifications, and interactions that make up a software system Importance.
Virtual University - Human Computer Interaction 1 © Imran Hussain | UMT Imran Hussain University of Management and Technology (UMT) Lecture 16 HCI PROCESS.
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Engr. M. Fahad Khan Lecturer Software Engineering Department University Of Engineering & Technology Taxila.
Documenting a Software Architecture By Eng. Mohanned M. Dawoud.
Sixth Hour Lecture 10:30 – 11:20 am, September 9 Framework for a Software Management Process – Artifacts of the Process (Part II, Chapter 6 of Royce’ book)
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Requirements Analysis CS 414 – Software Engineering I Donald J. Bagert Rose-Hulman Institute of Technology January 7, 2003.
Software Testing and Quality Assurance
CAP 252 Lecture Topic: Requirement Analysis Class Exercise: Use Cases.
OO Development Process. UML and Process UML standardizes notation, not process –Increase likelihood of widespread acceptance There is significant variability.
Week 8 Implementation Design Alex Baker. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what.
Analysis Concepts and Principles
Fundamentals of Information Systems, Second Edition
Team Skill 6 - Building The Right System Part 1: Applying Use Cases (Chapters of the requirements text) CSSE 371 Software Requirements and Specification.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
© Copyright Eliyahu Brutman Programming Techniques Course.
Software engineering Olli Alm Lecture 2: requirements, modelling & representation.
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Object Oriented Analysis and Design Using the UML
Information Security Governance 25 th June 2007 Gordon Micallef Vice President – ISACA MALTA CHAPTER.
Copyright © Craig Larman All Rights Reserved Requirements.
 A project is “a unique endeavor to produce a set of deliverables within clearly specified time, cost and quality constraints”
S/W Project Management
UML - Development Process 1 Software Development Process Using UML (2)
Business Analysis and Essential Competencies
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Team Skill 6: Building the Right System From Use Cases to Implementation (25)
CEN rd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Phases of Software.
Role-Based Guide to the RUP Architect. 2 Mission of an Architect A software architect leads and coordinates technical activities and artifacts throughout.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
University of Southern California Center for Systems and Software Engineering Model-Based Software Engineering Supannika Koolmanojwong Spring 2013.
Chapter 7 Applying UML and Patterns Craig Larman
Project Plan. Project Plan Components Project Overview – Description and Strategy Business Case Summary Key Deliverables and Scope Critical Success Factors.
CS 4310: Software Engineering Lecture 4 System Modeling The Analysis Stage.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Session 9 Component and Deployment. OOAD with UML / Session 9 / 2 of 17 Review State Diagrams represent the software entities in terms of their states.
ARCH-2: UML From Design to Implementation using UML Frank Beusenberg Senior Technical Consultant.
CS 4850: Senior Project Fall 2014 Object-Oriented Design.
The Role of Experience in Software Testing Practice Zahra Molaei Soheil Hedayatitezengi Comp 587 Prof. Lingard 1 of 21.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 1: Introduction to Use-Case Modeling.
Requirement Handling
Software Engineering COSC 4460 Class 4 Cherry Owen.
Inception Chapter 4 Applying UML and Patterns -Craig Larman.
Rational Unified Process (RUP) Process Meta-model Inception Phase These notes adopted and slightly modified from “RUP Made Easy”, provided by the IBM Academic.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
Software Development A Proposed Process and Methodology.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Requirement Engineering. Recap Elaboration Behavioral Modeling State Diagram Sequence Diagram Negotiation.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Rational Unified Process (RUP)
® IBM Software Group © 2009 IBM Corporation Essentials of Modeling with the IBM Rational Software Architect, V7.5 Module 15: Traceability and Static Analysis.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
4+1 View Model of Software Architecture
Refining the Use Cases 1. How Use Cases Evolve  Early efforts typically define most of the major use cases.  The refining stages complete the process.
SynergySoft™ Distributed Meeting Scheduler Requirements Review Yasaman Haghpanah Ravindra Rudraraju Sowjanya Sakruti Jim Whitaker.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
CONNECTING COMPONENT Pertemuan Matakuliah: M Analisis dan Perancangan Sistem Informasi Lanjut Tahun:
Design and implementation Chapter 7 – Lecture 1. Design and implementation Software design and implementation is the stage in the software engineering.
From Use Cases to Implementation 1. Structural and Behavioral Aspects of Collaborations  Two aspects of Collaborations Structural – specifies the static.
From Use Cases to Implementation 1. Mapping Requirements Directly to Design and Code  For many, if not most, of our requirements it is relatively easy.
VA Internal Use Only 1 Product Architecture Recommendation Briefing Template.
Component and Deployment
4+1 View Model of Software Architecture
4+1 View Model of Software Architecture
Presentation transcript:

1 Essential Software Architecture Documenting a Software Architecture

2 Architecture Documentation Architecture documentation is a thorny issue Commonly there is no documentation covering the architecture.  If it is, it’s out-of-date, inappropriate and basically not very useful. Also projects that have masses of architecture related information  Sometimes invaluable, but often it’s out-of-date, inappropriate and not very useful!

3 Documenting an Architecture is good! Others can understand/evaluate the design. We can understand the design after a period of time. Others in the project team and development organization can learn from the architecture. We can do analysis on the design, perhaps to assess its likely performance, or to generate standard metrics.

4 But it’s difficult … No universally accepted architecture documentation standard. An architecture can be complex, and documenting it in a comprehensible manner is time consuming and non-trivial. An architecture has many possible views. Documenting all the potentially useful ones is time consuming and expensive. An architecture design often evolves Keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project.

5 Think carefully about what to document Project complexity  A small project may only need a ‘marketecture’ Project longevity  One-off stop gap software?  Strategic, long-term, will evolve? Needs of stakeholders  Small team, a whiteboard might be ok  Large, dislocated team needs more  Integrators? Testers? Programmers? Need to spend documentation dollars/euros wisely on high value products

6 UML 2.0 UML is a powerful way to document an architecture Provides a relatively formal, unambiguous description New features in UML 2.0 appropriate for architectures Good tools available, some free Can be used to depict various structural/behavioral architecture views

7 Component Diagram

8 Class Diagram

9 Sequence Diagram

10 Deployment Diagram

11 Component Interfaces

12 Component Decomposition

13 Document Template Documentation is easier if there’s a template to use  Reduces start-up time for projects by providing ready-made document structures  familiarity gained with the document structure aids in the efficient capture of project design details.  help with the training of new staff

14 Template Headings Architecture Documentation Template Project Name: XXX 1Project Context 2Architecture Requirements 2.1Overview of Key Objectives 2.2Architecture Use Cases 2.3Stakeholder Architectural Requirements 2.4Constraints 2.5Non-functional Requirements 2.6Risks 3Solution 3.1Relevant Architectural Patterns 3.2Architecture Overview 3.3Structural Views 3.4 Behavioral Views 3.5Implementation Issues 4Architecture Analysis 4.1 Scenario analysis 4.2Risks

15 Summary Some documentation is nearly always a good idea Trick is to produce ‘just enough’ and no more  requires upfront planning and thinking  Commitment to keeps docs current UML 2.0 makes architecture documentation easier Some good UML 2.0 tools, try ‘em out.