1. Of course, you should start your software MDWorkbench.
2. Create your project; the name of my project is “TestEFFBD”.
   1. Click: File -> New -> Project
   2. Click: General -> Project
   3. Project name: TestEFFBD
   4. Finish
3. Create new model; I assign the name is “Test”
   1. Right click on TestEFFBD -> New -> Other
   2. Click: MDWorkbench -> Model
   3. Click: Defense -> Finish
4. You should find the window like below picture:
   
5. In Type windows select: Functional Entities -> Scenario
6. Right click on Scenario-> Right click -> New -> Scenario
7. Name: High level scenario
8. In Reference Windows click: New
9. In Choose a Type: Select Expresses The Dynamic Of -> OK
10. Name: Mother function
    
11. Now you can modify the eFFBD diagram !!!
12. On menu bar, Click: Window -> Show View -> Diagram

    

13. Perfect!!!

• Configuration management goal => to have the necessary data for building again the same product.
• That means that for the software we need:
  • To have all the file used for the software builds: source files, data files, parameterization files.
  • The production tools: compiler, makefile (options and order of compilation, libraries)
  • The operation environment: operating system, firmware, hardware, COTS(Components Of The Shelf)
• All the manufacturing data are configuration data of the software product.
  
• The hardware configuration data are mainly documents: URD, TRD, drawing, user manual.
• The software configuration data may be only in an electronic form: source code, test source code, test data.

• Software Configuration Management process
  • Identification of the items:
    • A software component is an item whose definition and its related changes shall be controlled during the product lifecycle.
      • Any software components are individually identified.
      • An intermediate file is not always a software component (i.e. OBJ file)
    • A software product is a software component tree, equivalent to product tree.
  • Configuration management of the software:
    • Specification
      (ข้อมูลจำเพาะ) of dependences between the components.
    • Data persistence (การคงอยู่)
    • The dependence(ไม่มีอิสระ)
      rules between these data allow to:
      • Manage the consistency between the software components.
      • Optimize the performances for introducing modifications (duration of recompilation)
  • Configuration status accounting: To keep the track of the software releases for helping to analyze the problems (deliveries, changes).
  • Configuration verification: To ensure the consistence between the software components.
• The working spaces
  • On a development station, identifying working spaces allows to:
    • Freeze the content of each object at the end of phases.
    • Formalize the transfer of each object to the next phase.
    • Give the right visibility according to the profile of the other software developers.
    • Control the use of the software in the manufacturing process.
    • Archive the validated status.
    • Minimize the amount of the stored data by avoiding uncontrolled copies of data.
  • Rules of managing the data shall be defined:
    • People or organisms access rights to the different workspaces according to their function and responsibility.
    • Type of access (read, write) and mode of access (authentication with a password required).
    • Each workspace shall be lead by a unique responsible.
• Version control
  • Version number: similar to the major index.
  • Revision number: similar to the minor index.
  • Variant (แปรปรวน, แตกต่าง): operating system, hardware, option.
  • Provisional version: not integrated to the reference space.
  • Signature: value of a control sum performed on the content of the item.
• SCM tools functionalities
  • Release control
  • Working spaces
    • “View” mechanism: allows the tools and commands to have an access to the data according to the context.
    • Parameterization of views
    • Access right management
  • Build management:
    • Detection of dependences between the source files
    • The build audit allows to:
      • Have an operation traceability (who, when, on which computer)
      • To know:
        • The used files.
        • The environment.
        • The production scripts.
  • Process control:
    • Objectives:
      • To put on place the procedures of the organization.
      • Interoperability with the other tools of the software factory (compiler, design tool, debugger).
• Software configuration management plan
  • In addition to the general configuration management plan content, some additional features are added in the case of the software:
    • Definition of the working spaces and access rights.
    • Data save guard procedures.
    • Internal and external identification of the software.
    • Use of the development tools.
    • Changes tracking in the configuration management tools.
    • Identification and marking of the files (source, test)
• Reference documents: The following documents include a section on the configuration management:
  • ISO 12207: Information processing – Software engineer
  • ECSS-E-40-Part 1_B: Software – Principles and requirements.
  • ECSS-E-40-Part 2_B: Software – Document Requirements Definition (templates)
  • ECSS-Q-80_B: Software product assurance.

• The contractual constrains
  
  • Phases A&B as dedicated contract(สัญญา)
    • Feasibility analysis
    • Prototypes
    • System parameters
  • Then the C/D phase contract
    • Validated Customer’s requirements
    • Secured development plan
    • Risks control
  • A contractual contains
    • Commercial terms
    • Applicable documents (AD, appendices of the contract)
      • Input documents for the project team
      • Set of requirements
        • Technical requirements
        • Programmatic requirements – Programmatic คือเอกสารพวก Statement of works
    • Technical requirements
      • User’s requirements
      • External interfaces requirements
      • Design requirements (thermal, mechanical, availability, radiations, qualification, environment)
    • Programmatic requirements
      • Management
      • Deliveries (Documentations and products)
      • Development (Prototypes, qualification, models)
      • Quality
      • Configuration management
      • ILS (Integrated Logistic Support)
    • Functional Configuration Baseline = Set of customer’s requirements at the beginning of the contract
      • Change product >> impact>> programmatic baseline.
      • Change programmatic >>impact>> technical baseline.
        ** The configuration management principles apply to the programmatic data.
    • Link between technical and programmatic data
    • Baseline establishment / review process.
      • The documentation is formally sent to a review team : The review data package
      • The comments are formalized by using RIDs (Review Item Discrepancy(ความไม่ลงรอยกัน,ความไม่ตรงกัน,ความขัดแย้ง))
      • During the review process, the RIDs are accepted or rejected.
      • After the review, the documentation is updated by including the accepted RIDs.
      • The baseline is established and formally approved: review close-out meeting.
• The Change Management
  • Level of responsibility of change
    • Cannot decide alone to apply a change if there is an impact on the customer’s requirements.
    • The customer has the authority for taking the decision, and will notify his decision to contractor.
  • Class of a change
    • Class 1: Change that affects approved technical specifications, including interfaces of the same level, and associated terms of the business agreement between a customer and his supplier.
      ** Needs of customer’s approval before any implementation.
    • Class 2: Change that does not fulfill class 1 change criteria
      ** Nevertheless, a class 2 change is sent for information to the customer which can decide to reclassify the change.
  • Class / Category
    • Class is related to the need to have an approval of the change by the customer.
    • Category is related to the interchangeability of the product.
  • Means
    • The Change Request (CR): Collects the information that formally defines a proposed project change versus the existing requirements.
    • The Change Proposal (CP): Is the vehicle for proposing a change to an approved baseline data or the business agreement.
    • The Change Notice (CN): Authorization by the customer to implement a change proposal (no specific format)
      ** For the change request and the change proposal, dedicated notices are used.
    • The Change File (CF): The change file gathers (ชุมนุม, รวมความคิด) all the information related to a change at the level of a product team.
  • The Change Request
    • Formalizes a modification of the baseline requirement:
      • Reformulation the impacted requirement
      • The new requirements are written.
      • A description and a justification of the change may be added.
    • A change Request is identified by its own reference.
    • The Change Request is emitted
      (ปล่อยออกมา) by a customer toward a subcontractor.
  • The Change Proposal
    • Describes the impact of a change on a product
    • Is formally approved
    • It is emitted by a subcontractor.
      • In response to a change request.
      • In a non solicited (เรียกร้อง) manner.
• The Request For Deviation
  (ความคลาดเคลื่อน, ความเบี่ยงเบน) (RFD)
  is the vehicle for requiring and agreeing the departure from a customer’s requirement that is part of an approved configuration baseline.
  • Content
    • Identification of the impacted document and requirement.
    • Its affectivity
    • The new wording of the requirement.
    • The justification of the deviation.
  • A RFD is identified by its own reference.
  • It is submitted to the customer’s approval.
  • The customer has several means for raising a request for deviation:
    • By submitting a request for deviation to the next upper level.
    • By using the design margins.
    • By having a compensation
      (การชดเชย) solution at his level.
  • The RFD/RFW process is done with respect to the product tree.
• The Request For Waiver is the vehicle for requiring and agreeing to the use or the delivery of a product that does not conform to its approved product configuration baseline.
  • Content
    • Identification of the related product item(s).
    • Affectivity of the waiver.
    • Identification of the impacted document.
    • Justification of the waiver.
  • A RFW is identified by its own reference.
  • It is submitted to the customer’s approval.
  • RFW processing
    • Similar to the RFD processing.
    • Waivers shall be limited to a number of items or a period of time.
    • The waiver will often need to identify a compensation solution on the system design.
• Contract impact on change management
  • The customer waits for the end of the test phase for taking a decision on submitted RFD.
  • A supplier’s change proposal is contractual and has a limit of validity. If the customer is not enough fast for notifying a change, the project team shall ask a new change proposal to the supplier.
  • Some suppliers require to be paid for reading a new version of a document.
    • We avoid to submitting new issues.
    • Several issue of a document is valid at a given time.
• Configuration Documents
  • For a given product, they are several types of documents:
    • Programmatic documents
    • Justification documents.
    • Configuration documents.
    • Other technical documents: Technical notes, test reports.
    • Project management documents.
    • Notices: CR, CP, RFD, RFW, NCR (Non Con-formance Report), RID.
  • Configuration documents according to the ECSS-M-40

• The configuration item (เริ่มเจาะรายละเอียด)
  • Starting point = the product tree
    • Breakdown of the system down to a level allowing
    • Each subsystem is seen as a black box by the other ones.
    • It is the kernel of the project structure and serves as main input for:
      • Configuration Management
      • Work Breakdown Structure
  • Configuration items selection:
    
    • Identification of the products that will be retained as configuration item.
      
    • The configuration items are identified at different levels of the product tree.
      
    • When a product has been selected as a configuration item, its father in the product tree is necessarily a configuration item.
      
    • The selection of the configuration items shell be performed in the same time than the WBS preparation because a configuration item has an influence on the WBS: reviews, documents deliveries, schedule…
      
  • Configuration items selection criteria:
    
    • Is the product critical from a safety, schedule or financials point of view?
      
    • Will the product require development of a new design or a significant (อย่างสำคัญ) modification to an existing design?
      
    • Does the product incorporate new or unproven technologies?
      
    • Does the product have an interface with hardware or software developed under another contract?
      
    • Is the item required for logistic support or activity?
      
    • Do all components of the product have common mission, installation and deployment requirements, common testing and acceptance?
      
• Configuration baselines: Approved status of requirements and design of product at project key milestone that serves as reference for activities the life cycle of the product.
  

  Product lifecycle
  System analysis -> Preliminary Definition -> Detailed Definition -> Production -> Utilization
  

  • The configuration baselines are supported by the product lifecycle.
  • Established at PRR (Preliminary Requirements Review)
  • Based on the URD (User Requirements Documents)
  • Functional Configuration Baseline
    • Established at SRR (System Requirements Review)
    • Based on the TRD (Technical Requirements Document)
  • Development Configuration Baseline
    • Established at PDR (Preliminary Design Review)
    • Based on : Internal architecture
    • URD of the products of the next lowest level, including interfaces.
  • Design baseline
    • Established at CDR (Critical Design Review)
    • Based on: Approved design of the product.
    • Tests specifications and procedures.
  • Product configuration baseline
    
    • Established at QR (Qualification Review) & AR (Acceptance Review).
    • Based on: All the data necessary for production, acceptance, operation, support and disposal.
  • The configuration baseline is formally established:
    • Review data package -> Prior to the review, the documentation is sent to the customer and/or to a review team.
    • The customer/review team will formalize his comments by using a dedicated form: RID (Review Item Discrepancy)
• As designed and as built configurations
  
  • Link between configuration baselines and as-designed configuration.
    
  • As designed configuration is composed of the last approved baseline and all the departure approved since the last baseline establishment.
    
  • What is a change?
    • Agreed evolution of a configuration baseline.
    • A change may be originated by
      • An anomaly.
      • An evolution of the need.
      • A bad understanding of the need.
      • A feasibility problem.
  • What is a deviation?
    • Permission to depart from the originally specified requirements for a product prior to realization.
      ** Note: A deviation permit is generally given for limited quantity of product or period of time, and for a specific use.
    • What is a Waiver (or concession)?
      • Permission to use or release a product that does not conform
        (เหมือนหรือคล้ายกัน) to specify requirements.
        
• The Configuration Control Board (CCB) is a regular meeting aiming at providing all the decisions related to the treatment
  (การดูแล, การทำให้คืนสภาพ) of the changes and departures.
  
• Identification marking: Each item, H/W and S/W is uniquely identified by a specific identification code.
  
  • This identification code allows distinguishing a product during its entire lifecycle.

ก็เลยขอแนะนำ อัลบัม ของอาผมเลยละกัน

ตอนนี้ข้อมูลยังไม่มีอะไรมาก ผมเองยังไม่แน่ใจว่า ออกเดี่ยวหรือออกเป็นวง แต่ที่แน่ๆ

นักร้องชื่อ : แม้ว สุจิน เกตุแก้ว

ชื่ออัลบัม : ลาบางกอก

เพลงเปิดตัวก็น่าจะเป็นเพลงนี้ เหมือนกัน : ลาบางกอก

รายชื่อเพลงทั้งหมด

1. ลาบางกอก
2. ใต้แสงจันทรา
3. สตางค์
4. มาเลเซีย
5. นางฟ้าเดินเดิน
6. คอร์ด C กีตาร์เซอร์
7. ลงแดง
8. คนสำคัญ
9. ให้เธอ

รูปหน้าปกเดี๋ยวจะตามมานะครับ..ให้น้องมันส่งมาให้อยู่

หน้าปกหน้า แม้ว ลาบางกอก

หน้าปกหลัง แม้ว ลาบางกอก

ถ้าพูดถึง Deployment Diagram นั้นจะมีองค์ประกอบที่สำคัญคือ Node ซึ่ง Node นี้จะเหมือนกับ Components ทุกอย่าง เพียงแต่จะเน้นในการนำเสนอข้อมูลในด้านของ Computational resource, memory ที่น้อยที่สุดที่สามารถทำงานได้, ความสามารถในการประมวลผลของคอมพิวเตอร์ ฯลฯ

อย่างที่ได้กล่าวมาแล้วว่า เวลาเรา Design System มันก็มักจะแบ่งออกเป็น 2 ส่วนคือ Logical กับ Physical ไอ้ logical ส่วนใหญ่ก็จะเป็น Classes, Interfaces, Collaborations, Interactions และ State machines แต่ถ้าเป็นส่วนของ Physical นั้นก็จะมีอยู่แค่ 2 อย่าง คือ Components(ซึ่งเป็นการนำ Logical มายัดไว้เป็น Package) และ Node (จะแสดงให้เห็น Hardware ซึ่งจะถูกเอาไป Deployed และ Executed)

ตัวอย่าง

ที่มา :

http://www.sparxsystems.com

Component Diagram จะเป็น Diagram ที่ใช้ในการแสดง Model ที่นำเสนอในส่วนของ Physical view (Class Diagram จะเป็นแบบ Logical view) เช่น ไฟล์ Executables, Libraries, Tables, files และ Documents สรุปง่ายๆ Component Diagram ก็คือ Class Diagram ที่เน้นในส่วนของ Components ของ System

จุดประสงค์อีกอย่างหนึ่งของ Component Diagram ก็คือาการที่สามารถนำมา Component เหล่านั้นกลับมาใช้ได้ใหม่ (Reuse) นอกจากนี้มันยังสามารถทำหน้าที่ในการให้ความช่วยเหลือ (Provide) หรือสามารถเรียกการใช้งานของ Interface อื่นๆ ก็ได้ด้วยเช่นกัน

เท่าที่เห็นตอนนี้ เค้ามักจะใช้ Component Diagram ติดต่อกับ Component Diagram ด้วยกัน หรือ ไม่ก็กับ Interface

ตัวอย่าง

Terms & Concepts

1. External View (Black box) เน้นไปที่การแสดงให้เห็นถึงการ Provide Interfaces และ Require Interfaces
2. Internal View (White box) เน้นไปที่การแสดงให้เห็นถึงโครงสร้างภายในของ Component ซึ่งจะทำให้เราเห็นว่าภายใน Component ต่างๆ นั้นประกอบด้วย Components อื่นๆ หรือ Class อะไรอื่นๆ อีกได้บ้าง (ภายใน Component ก็สามารถที่จะมี Sub-Components ได้เหมือนกัน)
3. Hierarchical View ก็อย่างที่บอกไปว่าใน Component นั้นสามารถที่จะสร้าง Sub-Component เข้าไปในตัวของมันเองได้อีกด้วย โดยการติดต่อกันภายในก็จะอาศัย Ports, Connectors และ Property/Parts

Relation ระหว่าง Component กับ Interface นั้นสามารถแบ่งออกได้เป็น 2 แบบ คือ

1. Realization relationship เป็น Relation ที่ใช้ในกรณีที่ Component ทำหน้าที่ Require Function จาก Interface
2. Dependency relationship เป็น Relation ที่ใช้ในกรณีที่ Component ทำหน้าที่ Provide Function ให้กับ Interface (ให้ Interface มาเรียน นั่นเอง)

ที่มา :

http://www.sparxsystems.com/resources/uml2_tutorial/uml2_componentdiagram.html

Composite Structure Diagram เป็น Diagram หนึ่งที่อยู่ในกลุ่มของ Structural Modeling Diagram โดย Composite Structure Diagram นี้จะมีหน้าที่ในการที่จะแสดงให้เห็นความหมายของโครงสร้างของชั้นต่างๆของ Element และจะเน้นในรายละเอียดของโครงสร้าง และ ความสัมพันธ์ ภายในโครงสร้างนั้นๆ รวมไปถึงการมีจุด Interconnection กับส่วนอื่นๆ ของ System

Example

ส่วนประกอบของ Composite Structure Diagram
 

1. Part/Property คือองค์ประกอบ(Element)ที่อยู่ใน Class ที่เราสร้างขึ้นนั้นเองสามารถมีได้มากกว่า 1 Part ใน 1 Class นั้นๆ จากรูปด้านบนจะเห็นว่าใน Class FibonacciSystem จะมี part ด้วยกันทั้งหมด 5 Parts คือ FibonacciFunction, NMinus2, NMinus1, N และ Viewer
2. Port คือ จุดที่ให้เอาเชื่อมต่อระหว่าง Part กับ Part หรือ Part กับ Environment สัญลักษณ์ก็จะเป็นรูปสี่เหลี่ยมจตุรัส วางไว้บนกรอบของ Class อย่าลืมว่า Port นั้นต้อง Set ให้เห็น Privateในกรณีที่ติดต่อกันภายใน Class เดียวกัน แต่ถ้าต้องการติดต่อกับภายนอกถึงใช้ Public
3. Connector คือ เส้นตรงที่ทำหน้าที่เชื่อมต่อระหว่าง Port กับ Port (Port นะครับไม่ใช่ Part)หรือ Part กับ Environment
4. Collaboration คือ Classifier ชนิดหนึ่งที่มีทำหน้าที่ในการ รวมรวม Operation/Function ที่อยู่ใน Class อื่นๆ มาไว้ในตัวของมัน เช่น
   
   
5. Structure Classifier ก็คือ Class ที่ยอมให้ไอ้ 4 ตัวที่กล่าวมาข้างบน..มาอยู่ใน Class ของตัวมันนั่นเอง ซึ่งจากรูป ไอ้ Class FibonacciSystem ก็คือ Structure Classifier นั่นเอง
6. Encapsulated Classifier ก็คือ Structure classifier ชนิดหนึ่งที่ต้องมี Ports อยู่ภายใน Class จากตัวอย่างก็จะเห็นว่า ทั้ง Class Variable และ FibonacciSystem ต่างก็เป็น Encapsulated classifier เพราะว่าทั้ง 2 class มี Port อยู่ภายในนั้นเอง

ที่มา :

http://en.wikipedia.org/wiki/Composite_structure_diagram
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_compositediagram.html

ก่อนหน้านั้นคุยกันเรื่อง State machine ไปวันนี้กลับมาต่อกันในหัวข้อเรื่อง Activities

• Action
• Activity
• Edge (automatic transition)
• Swinlanes (Partition)

สิ่งที่แตกต่างระหว่าง State machine และ Acitivities diagram นั่นก็คือ

• State machine จะแสดงให้เห็นการควบคุมการทำงานของ State หนึ่ง ไปยังอีก State หนึ่ง
• Activities นั้นจะแสดงให้เห็นลำดับการเคลื่อนที่ของการควบคุมการทำงานและการเคลื่อนที่ของข้อมูล (Control flow & data flow) จาก Activity หนึ่งไปยังอีก Activity หนึ่ง

Activity diagram จะประกอบด้วย

• Activity(Node), action, Object/Data
• Activity edge
• Threads

Example

Picture : http://cormas.cirad.fr/images/applica/JLB-shepherdActivity.gif

Action

    การทำงานบางอย่างเพื่อแสดงให้เห็นว่ามีเปลี่ยนแปลง หรือ ดำเนินการ บางอย่างใน Model เช่นมันสามารถที่จะ ส่งสัญญาณ, สร้างหรือทำลาย Object

Activity

    คือการกำหนด paramiter บางอย่างของ Behavior เพื่อที่จะได้สั่งให้ Subordinate นั้นทำงานได้อย่างถูกต้องตามลำดับ โดย Activity สามารถที่จะประกอบไปด้วย Action ที่แตกต่างกัน

Edge

    คือ connection ที่ถูกสร้างขึ้นเพื่อให้ทำงานระหว่าง Activity Nodes โดยรวมไปถึง การควบคุมและเคลื่อนที่ของ Edge อีกด้วย สิ่งสำคัญอีกอย่างหนึ่งก็คือ Guard โดยทำให้ Edge นั่นสามารถที่จะตรวจสอบตรรกะได้ เช่นถ้าเป็นจริงให้ผ่าน.ถ้าเป็นเท็จก็ไม่ยอมให้ส่งข้อมูลหรือการควบคุมต่างๆ นั้นผ่านไปได้

Decision node

    ช่วยเข้ามาควบคุม Node ในการเลือกว่าจะไปทางไหน ของ Outgoing flows

Picture : http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_users_guide/images/spec_mergedecisionnodes.png

Join node

    ทำหน้าที่ในการทำ multiple flow มาเป็น Input แล้วมี Outgoing flow อันเดียว นอกจากนี้ยังสามารถนำ multiple incoming edges มารวมกันแล้วให้กลายเป็น Outgoign Edge เพียงอันเดียวได้อีกด้วย

Picture : http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_users_guide/images/spec_forkjoinnodes.png

Activity partition

    เป็นตัวช่วยในการแบ่ง Activiy nodes และ edges เป็นส่วนๆ และ แบ่งกลุ่มของ Node โดยมากมักถูกใช้งานในส่วนของ Business model นอกจากนี้มันยังสามารถที่จะแบ่งตามลำดับชั้นและแบ่งออกได้เป็นตารางอีกด้วย

ตัวอย่าง

Picture : http://www.gentleware.com/fileadmin/media/archives/userguides/poseidon_users_guide/images/activity_partition.png

Pin

    Element ที่สามารถให้ข้อมูลไปยัง Action และ ยอมรับผลลัพธ์จาก Action เหล่านั้นได้อีกด้วย โดย Pin สามารถที่จะกำหนด Specify Argument, return ค่าต่างๆ หรือ กำหนด Parameter ได้ เห็น อาจารย์เค้ายกตัวอย่างตอนที่เอามาเขียน Model ของโปรแกรมที่มีการ ใส่ Argument

1. ใช้ร่วมกับ Interface

2. ใช้ร่วมกับ Collaboration

แต่โดยส่วนใหญ่แล้ว Realization นั้นมักจะถูกนำมาใช้กันระหว่าง Interface กับ class หรือ component มากกว่า (Collaboration จะน้อยมาก) โดย Interface มักจะมี service มารองรับการทำงานร่วมกับ Class/Component (ให้ Class/Component มาเรียกใช้ Service ที่ Interface มีนั่นเอง) 

ในการแสดง..รูปแบบของ Realization Relation นัั้นจะมีอยู่  2 แบบ คือ

1. Canonical form (เหมือนรูปด้านบน)
2. Elided form (แฮะๆ..หารูปไม่เจอ..แสดงว่าไม่นิยมใช้)

นอกจากนี้เรายังนำ Realization มาใช้ร่วมกันระหว่าง Use case กับ Collaboration แต่จะแสดงในรูปของ Canonical form เท่านั้น