Software Patterns Dr. M.E. Fayad, Professor

Slides:



Advertisements
Similar presentations
IT Requirements Capture Process. Motivation for this seminar Discovering system requirements is hard. Formally testing use case conformance is hard. We.
Advertisements

Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
Fall 2002 SJSU -- CmpE Enterprise & Application Frameworks Dr. M.E. Fayad, Professor Computer Engineering Department – RM# College of Engineering San José.
L3-1-S1 OO Concepts © M.E. Fayad SJSU -- CMPE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room.
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
L3-5c-S1 Object Diagrams © M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department,
L16-S1 Object Diagrams 2003 SJSU -- CmpE Software Patterns Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
L28-S1 Interaction Diagrams 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room.
May-June 2001 ISISTAN Research Institute – Tandil, Argentina Software Design Methodologies: UML in Action Dr. Mohamed Fayad, J.D. Edwards Professor Department.
L19-S1 More on Class Diagrams 2003 SJSU -- CmpE Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
L21-S1 Model-Based Arch SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
L3-5d-S1 Class Diagrams © M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
L26-S1 Interactions 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
© M.E. Fayad SJSU -- CmpE Database Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San José.
L5-S1 Class Diagrams 2003 SJSU -- CmpE Software Patterns Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San.
L8-S1 CRC Cards 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
© M.E. Fayad SJSU -- CmpE Analysis Heuristics Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
 Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San.
© M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
L04-S1 Stable Design Patterns 2003 SJSU -- CmpE Software Patterns Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering.
L3-6b-S1 Sequence Diagrams © M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department, Room.
L6-1-S1Design Heuristics - 1 © M.E. Fayad SJSU -- CmpE Software System Engineering Dr. M.E. Fayad, Professor Computer Engineering Department,
Object-Oriented Analysis and Design
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
L6-S1 UML Overview 2003 SJSU -- CmpE Advanced Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College.
Fall 2002 SJSU -- CMPE Object-Oriented Analysis & Design Dr. M.E. Fayad, Professor Computer Engineering Department – RM# College of Engineering San José.
UML (Unified Modeling Language)
OO DomainModeling With UML Class Diagrams and CRC Cards Chapter 6 Princess Nourah bint Abdulrahman University College of Computer and Information Sciences.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
Diagrams. Typically, we view the static parts of a system using one of the four following diagrams. 1. Class diagram 2. Object diagram 3. Component diagram.
L1-S1 Infinite R-DB 2003 SJSU -- CmpE Database Design Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 6 Slide 1 Software Requirements (utvalgte foiler fra Kap 6 og 7 i Sommerville)
1 Team Skill 3 Defining the System Part 1: Use Case Modeling Noureddine Abbadeni Al-Ain University of Science and Technology College of Engineering and.
Systems Analysis and Design in a Changing World, Fourth Edition
UML Diagrams: Class Diagrams The Static Analysis Model
Course Outcomes of Object Oriented Modeling Design (17630,C604)
Advanced Object-Oriented Analysis & Design
Software Engineering Management
Reference: COS240 Syllabus
OO Domain Modeling With UML Class Diagrams and CRC Cards
Component-Based & Software Reuse
Software System Engineering
Object-Oriented Analysis & Design
Use Cases CS/SWE 421 Introduction to Software Engineering Dan Fleck
Unified Modeling Language
Software Engineering Management
Advanced Object-Oriented Analysis & Design
DESIGNING YOUR SYSTEM.
Analysis models and design models
Software Design Lecture : 15.
Software System Engineering
Software System Engineering
Chapter 5 Understanding Requirements.
Advanced Object-Oriented Analysis & Design
Object-Oriented Analysis & Design
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Advanced Object-Oriented Analysis & Design
Component Based & Software Reuse
Advanced Object-Oriented Analysis & Design
Software System Engineering
Software Development Process Using UML Recap
UML  UML stands for Unified Modeling Language. It is a standard which is mainly used for creating object- oriented, meaningful documentation models for.
Presentation transcript:

Software Patterns Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I College of Engineering San José State University One Washington Square San José, CA 95192-0180 http://www.engr.sjsu.edu/~fayad 2003 SJSU -- CmpE

Documentation Template Lesson 5: Documentation Template 2 2003 SJSU – CmpE --- M.E. Fayad

3 Lesson Objectives Understand why pattern documentation patterns Learn how to document patterns Explore each section of the template by example. Understand the tips, rules, and guidelines for documenting each section. 3 2003 SJSU – CmpE --- M.E. Fayad

Documentation Templates Basically, there are two types of templates for documenting stable patterns: 1. Full Template. Each stable pattern should have a full template that gives a detailed documentation for that pattern. The full template consists of 14 fields that will be discussed in details in the next section. 2. Short Template. A short template is a reduced size version of the full template. This template is usually used to document the pattern when this pattern appears within the main pattern that we are interested in documenting it. Short template consists only five fields. 4 2003 SJSU – CmpE --- M.E. Fayad

5 Full Template Pattern Name Problem Context Forces Solution -- Pattern structure Participants CRC Cards Behavior Model Consequences Applicability with illustrated Examples Related Patterns Design/Implementation Issues Formalization Known Uses Several Perspectives 5 2003 SJSU – CmpE --- M.E. Fayad

6 Short Template Pattern Name Problem Context Solution -- Pattern structure Participants 6 2003 SJSU – CmpE --- M.E. Fayad

7 Pattern Name Presents the name of the presented pattern. Gives a focus and precise name for the pattern to be described. Choose the patterns’ names carefully. Patterns’ names should be natural, and descriptive, and unambiguous. Pattern names are very essential for understanding the purpose of the pattern. 7 2003 SJSU – CmpE --- M.E. Fayad

Pattern Name: Rules Pattern names should be bold and italic whenever they appear in the text. It is a single word or a short phrase. 8 2003 SJSU – CmpE --- M.E. Fayad

9 Pattern Name: Tips Name has to be a meaningful and natural name. Name must refer to the atomic concept and the core knowledge of the pattern. It has to be unique and descriptive and only refer to the pattern that describes. Multiple names cause confusion but it cannot be avoided. In this case the Aliases must be stated if applicable. Pattern names must imply the characteristics of EBTs or BOs 9 2003 SJSU – CmpE --- M.E. Fayad

Problem Presents precisely and briefly the problem this pattern addresses. It is preferred that the problem is presented in the form of a question. For instance, for the pattern named “Negotiation” the problem could be described in the question: How does one build a negotiation model that can be used to model the negotiation problem in any application? 10 2003 SJSU – CmpE --- M.E. Fayad

Context Gives the boundaries of the problem and preconditions in which the pattern may recur. This must be discussed thoroughly to avoid critic. Context -- Rules: Context must be clearly described. List all the preconditions for which the solution is valuable. 11 2003 SJSU – CmpE --- M.E. Fayad

Forces Illustrates the challenges and the constraints that the pattern needs to resolve. Discusses the issue of the problem and the trade off between these issues. It is expected that reading these forces will help the reader in realizing the difficulty of the problem, while at the same time it helps him to appreciate the importance of having a solution to this problem. It must discuss problem’s constraints. Forces and constraints may contradict with one another. 12 2003 SJSU – CmpE --- M.E. Fayad

13 Forces: Rules Forces represent the “Why?” Forces also represent the problem’s constraints. Forces expose the particulars of the problem. Forces must be listed based on their priorities. 13 2003 SJSU – CmpE --- M.E. Fayad

Solution – Four Parts a) Static structure, which is stable object model or pattern structure. Static structure reveals the structure of the pattern that contains it participants and the relationships among them. We use UML notation and guidelines for generating the pattern structure. The solution must be described and it may contain pictures, diagrams, textual templates, descriptive artifacts, etc. b) Participants c) CRC Cards d) Dynamic behavior will be illustrated and discussed in the applicability of the pattern. 14 2003 SJSU – CmpE --- M.E. Fayad

Pattern Structure (1) Gives the class diagram of the pattern (EBT or BO). It also introduces briefly each class and its role. Associations, aggregations, dependencies, and specializations should be included in the class diagram. Association classes, constraints, interfaces, tagged values, and notes must be included in the class diagram. A full description of the class diagram should be included. 15 2003 SJSU – CmpE --- M.E. Fayad

Pattern Structure (2) This part shows and describes briefly the stable object model of the pattern. We present two class diagrams for each pattern, one is brief version of the class diagram, where only the name of the classes and patterns and their relationships are shown. The other class diagram is the detailed one where operations and attributes are added to each class and pattern. 16 2003 SJSU – CmpE --- M.E. Fayad

Pattern Structure: Tag Names <EBT> Class <BO> Class <IO> Class <Pattern-EBT> Pattern represents stable analysis pattern <Pattern-BO> Pattern represents stable design pattern 17 2003 SJSU – CmpE --- M.E. Fayad

Pattern Structure: Rules & Heuristics Follow UML Use tagged value Heuristics ·      EBTs or Pattern-EBT’s multiplicities is usually one or a fix number of instances. Avoid many to many relationship. 18 2003 SJSU – CmpE --- M.E. Fayad

Participants (1) The participants of any pattern can be classified into two main categories: Classes and Patterns. The participants of the pattern are: 1. Classes. List all the classes in the pattern and a short description for each. 2. Patterns. List all the patterns in the main pattern and a short decription for each 19 2003 SJSU – CmpE --- M.E. Fayad

Participants: Rules (Pattern-EBT = Stable Analysis Pattern, or Pattern-BO = Stable Design Pattern) EBTs usually do not have multiplicity around them (always considered to be 1, or a fixed number or a range if you are not sure.) Between any two components in the pattern class diagram the multiplicity, roles, and relationship names should be added. 20 2003 SJSU – CmpE --- M.E. Fayad

21 CRC Cards: Rules A Role must be specified per the card’s class. Each CRC-Card should contain one and only one responsibility. This responsibility has to be unique and it must be specified within context. The Clients names are listed under each other without using bullets or dashes. Server part should contain all the services provided by the current Class/Pattern listed without bullets. Each severs will be written as an operation starting with small letter and has two curve parenthesizes at the end. Classes with multiple roles, such as actors, must have a CRC card per role. 21 2003 SJSU – CmpE --- M.E. Fayad

CRC Cards: Heuristics CRC Card filling process: 1. Identify the CRC card’s class name, 2. Name its role, 3. Name its responsibility under responsibility section, 5. List card class’s services (operations) under server and 6. Identify his clients in the client’s section. The clients must have direct or indirect relationships with the card class 22 2003 SJSU – CmpE --- M.E. Fayad

Consequences How does the pattern (EBT or BO) support its objectives? What are the trade-off and results of using the pattern? Nothing is perfect, and each problem has many issues that are usually hard, if not impossible, to be satisfied at once. This section lists the affect expected by using this pattern: good results (benefits), bad (drawbacks), ugly (which might cause major problems in specific situations), and the trade-offs (which shows what you gain versus what you scarifies from using this pattern in you development) 23 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (1) Provides clear and detailed case studies for applying the pattern in different contexts. This section shows how the pattern can be used in different applications. Usually, it is good to show the applicability of the pattern through two examples where each example has different nature. 24 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (2) For each case study the following subsections are usually filled: [a] Case Study # x: Case study name [b] Problem Description. This is a short problem statement about the case study where the pattern will be used. [c] Problem Class Diagram. Shows the class diagram of the problem with highlighting the original pattern in different color (gray, for instance). 25 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (3) In order to ease the reading of the stable model, each class should be located within its layer in the following format: EBTs BOs IOs 26 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (4) [d] Role-based Instance Diagram and Role-based Scenario for Pattern. Role- based Instance Diagram is a diagram that shows how can each pattern/class in the main pattern class diagram is instantiated in the example. It also shows how the pattern components interact with each others in the application soul. Figure, in the next slide, describes the symbols that are used in the Role- based instance diagram. The Role-based Scenario is a description of the role-based instance diagram in story wise, where each component in the pattern plays its role in the scenario. We found this story useful in gaining better understanding of the problem. In this scenario the pattern names are written in bold italic. The roles are written in bold and underlined 27 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (5) Represents the pattern name as given in the pattern object diagram Points to an instance of the pattern in the current application example. Represents the typical flow of the interactions within the application example. Represents a logical interaction between the different pattern within the application example. AnyView 2003 SJSU – CmpE --- M.E. Fayad

Applicability with Illustrated Examples (6) [e] Use Case Description. List 4-5 detailed use cases. Behavior Diagrams, such as Sequence Diagrams or STDs Sequence Diagrams A sequence diagram is a map of a giving use case. A sequence diagram usually forms a snake (only one snake) 29 2003 SJSU – CmpE --- M.E. Fayad

Design/Implementation Issues Specification Model for the Pattern represents the AnyParty’s view of the pattern; therefore, it describes what the AnyParty (i.e., user) may expect. The classes and relationships illustrate the vocabulary of the pattern requirements. Type Specifications. Hooks Description. Hooks are extension points on the BOs that can be adapted by AnyParty (e.g. application developers, users, operators). Each hook provides a specific requirement to be fulfilled by AnyParty and documents how to extend the pattern or the framework to meet the requirements. All BOs provide implemented hooks that can be utilized by IOs, application classes. 30 2003 SJSU – CmpE --- M.E. Fayad

Related Patterns Shows other patterns that usually interact with the described pattern, and those who are included within the described pattern. Related patterns can be classified as related analysis or design patterns and related design patterns. Related patterns usually share common forces and rationale. 31 2003 SJSU – CmpE --- M.E. Fayad

Formalization Using Z++ or Object Z Describes the pattern structure using the formal language (Z++ or Object Z) 32 2003 SJSU – CmpE --- M.E. Fayad

Known Uses Gives some examples of the uses of this pattern in existing systems (if the pattern has been already deployed before). Or it gives examples of existing system that can utilize this pattern as an alleviative to what they use currently 33 2003 SJSU – CmpE --- M.E. Fayad

Several Perspectives (Optional) This section of the template provide a brief discussion of the strategic impact of using the described pattern from the following perspectives: Budgetary Culture Technical Managerial Marketing Economic Impact 34 2003 SJSU – CmpE --- M.E. Fayad

Discussion Questions Use the pattern documentation template to document all EBTs (Stable Analysis Patterns) and all BOs (Stable Design Patterns) of the stable model (project #1). 35 2003 SJSU – CmpE --- M.E. Fayad