A Study on A Layer- and Architecture- based Agile Software Project Development Method

1. A Study on A Layer- and Architecture- based Agile Software Project Development Method Student: Chaoyu Lin1 Advisor: Dr. Weipang Yang3 and Dr. Jyhjong Lin2 1,3 Department of Information Management, National Dong Hwa University 2 Department of Information Management, Ming Chuan University

2. Software Development Method • Waterfall Process • 把軟體開發過程分成很多個階段，並假設: • 只要在需求階段進行分析 • 只要在設計階段進行設計 • … • 只要在個個階段能夠產生出正確無誤的文件，就能保證軟體專案開發的成功

3. 假設這樣是對的!

4. 能夠得到一份非常正確和完備，同時覆蓋所有需求(包含隱含需求)的設計文件，這在實務上是不太可能發生的…Why?能夠得到一份非常正確和完備，同時覆蓋所有需求(包含隱含需求)的設計文件，這在實務上是不太可能發生的…Why? • 瀑布法不能夠保證各階段的文件能夠被正確的轉換 • 瀑布法假定可以不需要其他任何東西，只根據需求文件就寫出覆蓋所有需求的設計文件 • 同樣的，瀑布法假定程式設計師可以對系統和需求一無所知，只要根據一份詳細設計文件就能把正確的程式碼開發出來 • 沒有任何的測試手段，能對這種轉換過程進行測試，從而保證其正確性

5. 軟體專案本質上就是一種高度複雜性的管理。 • 瀑布法承認這種複雜性，也透過劃分階段來分散複雜性 • 但正是這種對各個階段的嚴格劃分，不但提升了過程的複雜性，也引入了一個最大的隱憂 • 即無法在分析，設計與開發階段，都對其結果進行測試

8. 元件式軟體開發 • 軟體元件強調由其介面(Interface)及實作(Implementation)所組合而成，元件的實作通常不為外界所能看到(Visible)，且實作的修改並不影響使用端程式。 • 透過完整的介面定義對外連接(Connection)更容易達到再用效果(Reuse) • 軟體元件的開發應包含整體結構(Architecture)、領域塑模(Domain Modeling)、元件規格(Component Specification)等

9. 元件式軟體開發 • 使用物件導向分析與設計 • 物件導向程式設計，採用適當的元件介面規格，配合設計樣式(Design Patterns)及應用框架(Application Framework)的運用，將可執行程式包裝成軟體元件 • 或採用現成的軟體元件，佈署在應用伺服器上 • 藉由適度的再用性將軟體開發生產效益最大化

10. Architecture Design Patterns Application Framework Iterative Process

11. Identification and Motivation of the Method • the five most important items of Walker Royce’s Software Project Management: Base the process on an architecture-first approach. Establish an iterative life-cycle processthat confronts risk early. Transition design method to emphasize component-based development. Establish a change management environment. Enhance change freedom through tools that support round-trip engineering. Paulish’s Architecture-Centered Software Project Planning (ACSPP) [47]

12. From the above literature we can draw the following conclusions: • The architecture(i.e., high-level design) is the firstpoint to be addressed in the construction of the SDP. • The architectureis based on user requirementsand it is composed of distinct types of software components which collaborateto satisfy these user requirements. • The different types of software components have differentsoftware development processes and activities, also due to inherent different characteristics among user requirements and development teams, timelines for the completion of each project will vary. • All components that address each iteration for development must be identified, and also be integrated with a corresponding development process and constituent activities. This will produce a development plan (of course, the time needed for each development process will vary).

13. Issue 1 • It is necessary to clearly establish a software development process • under a specific software development plan • where modern software development focuses (such as architecture, components and iterations) are properly integrated.

14. The Development Method As shown in Figure 6, the method is a layer- and architecture-based with seven steps: The use case identification The conceptual components identification The architectural design and system components specification The development layer and activity order determination The instantiated system component design (software development framework independent) The software components design (software development framework dependent) The components implementation

15. The Development Method Step1. The use case identification described in an UML use case diagram, that clarifies user requirements to be satisfied in the system

16. As in many book publishing companies that offer various services such as • searching/viewing/ordering of books • sharing of writing experiences or organizing thoughts • writing or organizing of new books • Seven use cases can be identified and prescribed into three increments for further design and construction as shown below

18. The Development Method Step 2. The conceptual components identification, described in an UML robustness diagram that identifies conceptual components with each one playing a specific role in the realization of a desired use case.

19. Scenario #1 (view experiences shared from other users) 1)userinputsvia displaying HCI specific topics about shared experiences 2)systemreceivesthe topics 3)system retrieves the shared experiences under the topics 4)systemreturns the shared experiences under the topics 5)userviewsvia displaying HCI the shared experiences Scenario #2 (respond comments about shared experiences) 1)userinsertsvia responding HCI comments about shared experiences under specific topics 2)systemreceivesthe comments 3)system saves the comments under specific topics 4)systemreturns a confirmation 5)userviewsvia responding HCI the confirmation Scenario #3 (insert experiences to be shared with other users) 1)userinsertsvia insertion HCI experiences under specific topics 2)systemreceivesthe experiences 3)system saves the experiences under specific topics 4)systemreturns a confirmation 5)userviewsvia insertion HCI the confirmation Figure 32 Page 48

20. The Development Method Step 3. The architectural design and system components specification, described in UML-extended component diagrams, that employs platform specific features into architectural components such that each resultant system component has a specific implementation code on the chosen platform and hence its construction can be easily achieved by a direct transformation from its design work.

21. The architectural framework apply to the MVC-3

22. The architectural framework apply to the MVC-5

23. architectural design and appropriate technologies

24. architectural design and appropriate development frameworks

25. Design Pattern(demo in chapter 5) • Intercepting Filter pattern (page 49) • Front Controller pattern (page 50) • Command design pattern (page 51) • Service Locator pattern (page 51) • DAO (Data Access Object) design pattern

26. Design Patter (cont.)

27. specific code V.S. repetition code

31. The Development Method View View Control Model Model Control Step 4. The development layer and activity order determination that determines the layer and activity order for development of system components.

35. J. Shen, S. Changchien, and T. Lin, A Petri-Net Based Modeling Approach to Concurrent Software Engineering Tasks, Journal of Information Science and Engineering, vol. 21, (2005),767-795

37. Issue 2 • It is necessary to identify the development process and constituent activities for different types of components. • In addition to establishing the components, it is also essential to consider such work for existing components as upgrades, fixes, and enhancements • in order to effectively monitor and analyze the current progress, and estimate the future schedule.

38. For example, if A5 has been changed, it will restart from A1, A2, A3 or A4. If A4 is impacted, then the A7…will be impacted, too public enum Activity { A1("identify conceptual component") { @Override public Activity[] next() { Activity[] nextActivities = { A2 }; return nextActivities; } }, A2("construct view component") { @Override public Activity[] next() { Activity[] nextActivities = { A3,P1 }; return nextActivities; } },

39. For our example, suppose that a programmer ‘lendy’ is working in Activity.A1 (「identify conceptual component (A1)」) for the『displaying topics (IV1)』component under the use case ‘001’. Before programmer ‘lendy’ starts and ends his work in the code, he provides information about his working status by creating the following annotation instance annotation defines annotation instance

40. tracing program (page 34-35)

42. Page 60

44. design-orientedv.s. code-oriented • There are already plenty of software development methods in the literature. We just divide its into two models: • design-oriented models(more analysis and design work): • traditional generic model: Waterfall model, Evolutionary Development, Component-based …. • often used together for development of large systems: Rational Unified Process ,Spiral model • emphasize on the mathematical specification: B method and Cleanroom model • code-oriented models(criticize the overhead on design, less or even no analysis and design work): • Agile Development, Rapid Application Development (RAD) ,Extreme Programming (XP) • code work (i.e., implementation, testing, and refactoring) are focused • The two kinds (design- or code-oriented) of models, each one gets an extreme in its concerning spectrums • For the comprised approach that takes advantage of the two extreme kinds • However, such less design work on the other hand makes it lack sufficient mechanisms for supporting effective guidance on the development work

45. this research argues • each project should be individually tailored to fit distinct users’ needs • appropriate to produce enough artifacts • the development team can produce high-quality deliverables, • while the process (activities) can also follow the project properties and set the development steps (the SOP)

46. Issue 3 • Only after the software development team has established an architectural framework, will they clearly be able to ascertain which types of software componentsare needed to completetheartifacts. • In addition, the development team will need to follow the SOPto implement artifacts and code, which will improve the overall quality of the project.

47. The Development Method Step 5. The instantiated system component design (software development framework independent) that completes the instantiated design of system components that collaborate to achieve the use case/increment where the UML-extended component diagram is used as its modeling tool.